We have three cases where we allocate a texture that is larger than is needed: ...
12 years, 12 months ago
(2011-11-15 15:14:18 UTC)
#1
We have three cases where we allocate a texture that is larger than is needed:
1) GLs without NPOT texture support. The need for this is gone now that we no
longer support ES1.
2) iOS 3 and earlier didn't support small RT/textures so we rounded up to a min
size. (Also, one other platform that used similar SGX HW had this driver issue).
3) One gpu/driver combo did not allow NPOT textures to be bound to FBOs. It was
an old Intel GMA gpu and driver.
I'm proposing that we will no longer work around driver bugs for 2) and 3). I
don't think they are problems on platforms that we care about.
Going forward I'd like to add an abstraction above GrTexture called
GrTextureView. It would have a rectangle and a pixel config. The subrect defines
a domain in the texture. Texture coordinates are scaled to this domain
automatically by modifying the texture matrix sent to GL. The config would allow
the same scratch texture to be recycled both for requests that specify
RGBA_premul and RGBA_unpremul (since under the hood they use the same GL
format). This scheme would be useful for texture atlasing and simplify some of
the code that computes textures coords/mats for scratch textures that may no
match the requested width / height. If we had to reinstate workarounds for 2) or
3) I'd like them to use this framework rather than have each texture maintain
two widths/heights.
On some GPUs NPOT textures are supported but are less performant. We don't do
anything about this today. If we were to start rounding up textures on these
platforms to POT I'd rather use the GrTextureView scheme.
Issue 5373100: Remove allocated size vs content size in textures
(Closed)
Created 12 years, 12 months ago by bsalomon
Modified 12 years, 12 months ago
Reviewers: reed1, TomH
Base URL: http://skia.googlecode.com/svn/trunk/
Comments: 0