Age | Commit message (Collapse) | Author |
|
The encoding/decoding algorithms are shared with RGTC.
Thanks to some magic with the base format, the RGTC texstore functions work
for LATC too.
swrast passes the related piglit tests besides two things:
- The alpha channel is wrong (it's always 1), however the incorrect alpha
channel makes some other tests fail too, so I guess it's unrelated to LATC.
- Signed LATC fetches aren't correct yet (signed values are clamped to [0,1]),
however RGTC has the same problem.
Further testing (with other of my patches) shows that hardware drivers
and softpipe work.
BTW, ETQW uses this extension.
|
|
This adds support for the RGTC unsigned and signed
texture storage and fetch methods.
the code is a port of the DXT5 alpha compression code.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This was missed when implementing AL44.
|
|
|
|
This implements the extension by choosing a different set of texture
fetch functions when the texture parameter changes.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Make sure that all formats are handled in this function. It's
easy to miss this function when adding new pixel formats.
See also http://bugs.freedesktop.org/show_bug.cgi?id=31544
|
|
The BaseFormat field was incorrect for a few R and RG formats.
Fix a couple assertions too.
NOTE: This is a candidate for the 7.9 and 7.10 branches.
|
|
|
|
The case of format being MESA_FORMAT_COUNT should never occur.
|
|
According to the comment, the warning should be for debug builds.
|
|
|
|
|
|
|
|
Radeon GPUs can do this. R600 can even do render-to-texture.
Packing and extracting aren't implemented, but we shouldn't hit them (I think).
Tested with swrast, softpipe, and r300g.
|
|
Radeon GPUs do support GL_RGB10_A2.
|
|
|
|
|
|
|
|
NOTE: this is a candidate for the 7.9 branch
|
|
|
|
Be a bit more clear about its operation.
|
|
We only want to return true if it's an integer _color_ format, not a
depth and/or stencil format.
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=31143
|
|
|
|
If FEATURE_texture_s3tc is not defined, FXT1 formats would erroneously
fall through to the MESA_FORMAT_RGBA_FLOAT32 case.
|
|
|
|
Otherwise, FEATURE_EXT_texture_sRGB was undefined.
This is (part of?) the fix for fd.o bug 30177.
|
|
Due to a misunderstanding of the Z24_X8 and X8_Z24 formats, the earlier
patch created depth/stencil wrappers for them. This broke swrast.
Use the format info instead, which only identifies Z24_S8 and S8_Z24 as
packed depth/stencil. It also has the advantage of being nicer code.
Signed-off-by: Nick Bowler <nbowler@draconx.ca>
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
Intel sometimes uses packed depth/stencil buffers even when only a depth
buffer or only a stencil buffer was requested. Common code currently
uses the _BaseFormat field to determine whether a depth/stencil wrapper
is necessary. But unless the user explicitly requested a packed
depth/stencil buffer, the _BaseFormat field does not encode this
information, and the required wrappers are not created.
The problem was introduced by commit 45e76d2665b38b ("mesa: remove a
bunch of gl_renderbuffer fields"), which killed off the _ActualFormat
field upon which the decision to create a wrapper used to be made. This
patch changes the logic to use the Format field instead, which is more
like the old code.
Fixes fdo bug 27590.
Signed-off-by: Nick Bowler <nbowler@draconx.ca>
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
|
|
As defined by GL_EXT_texture_integer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
See bug 24806.
|
|
Fixes bugs 24798 and 24801.
|
|
|
|
|
|
|
|
|
|
24-bit Z in 32-bit pixel. We could probably use the MESA_FORMAT_S8_Z24
format but this there's a few places where we explicitly don't want stencil.
This format may go away at some point in the future.
|
|
|
|
|
|
|
|
|
|
|
|
|