Re: [Mesa-dev] [PATCH 7/9] mesa: Fill out ARB_texture_view entry points
On 12/04/2013 03:46 PM, Courtney Goeltzenleuchter wrote: It's come to my attention that Mesa's handling of GL_TEXTURE_BASE_LEVEL and GL_TEXTURE_MAX_LEVEL in glTexParameter and glGetTexParameter may be incorrect. The issue happens with the following sequence: glTexStorage2D(GL_TEXTURE_2D, 4, GL_RGBA8, 128, 128); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_BASE_LEVEL, 5); glGetTexParameter(GL_TEXTURE_2D, GL_TEXTURE_BASE_LEVEL, n); The key question is: What is the value of n? Right now, the Mesa driver will clamp the glTexParameter call to the range 0 .. 3 (as specified by the TexStorage call) and n = 3 after the GetTexParameter call. However, the value returned on the Intel Windows driver and NVIDIA's Linux driver return 5. This has apparently been discussed among Kronos members in bug: 9342 (https://cvs.khronos.org/bugzilla/show_bug.cgi?id=9342 https://urldefense.proofpoint.com/v1/url?u=https://cvs.khronos.org/bugzilla/show_bug.cgi?id%3D9342k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=SrPAWBW251dxCErQJNhB0m93E9Vb62KGHxK3yiRBRuU%3D%0As=a0c086b7a31a804e3e786118fd1771b53c85717a4cf0c8dea41b60e5acd0406b) which I don't have visibility of. To match that behavior the texture object will likely need two BaseLevel and MaxLevel attributes. One that's clamped and used locally and the other that simply holds the set value as given by the application in the glTexParameter call. Thoughts? From reading the bug report, it sounds like the ARB decided that clamping should be done when the texture is used, not when glTexParameter is called. In the GL 4.3 spec I don't see any language about clamping in glTexParameter either. We should be doing the use-time clamping already. So I think we just have to remove the clamping step in glTexParameter. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/9] mesa: Fill out ARB_texture_view entry points
Okay, that makes it easier. Should this change be conditional based on the type of context created? Courtney On Thu, Dec 5, 2013 at 8:52 AM, Brian Paul bri...@vmware.com wrote: On 12/04/2013 03:46 PM, Courtney Goeltzenleuchter wrote: It's come to my attention that Mesa's handling of GL_TEXTURE_BASE_LEVEL and GL_TEXTURE_MAX_LEVEL in glTexParameter and glGetTexParameter may be incorrect. The issue happens with the following sequence: glTexStorage2D(GL_TEXTURE_2D, 4, GL_RGBA8, 128, 128); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_BASE_LEVEL, 5); glGetTexParameter(GL_TEXTURE_2D, GL_TEXTURE_BASE_LEVEL, n); The key question is: What is the value of n? Right now, the Mesa driver will clamp the glTexParameter call to the range 0 .. 3 (as specified by the TexStorage call) and n = 3 after the GetTexParameter call. However, the value returned on the Intel Windows driver and NVIDIA's Linux driver return 5. This has apparently been discussed among Kronos members in bug: 9342 (https://cvs.khronos.org/bugzilla/show_bug.cgi?id=9342 https://urldefense.proofpoint.com/v1/url?u=https: //cvs.khronos.org/bugzilla/show_bug.cgi?id%3D9342k= oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ% 2BTLs8wadB%2BiIj9xpBY%3D%0Am=SrPAWBW251dxCErQJNhB0m93E9Vb62 KGHxK3yiRBRuU%3D%0As=a0c086b7a31a804e3e786118fd1771 b53c85717a4cf0c8dea41b60e5acd0406b) which I don't have visibility of. To match that behavior the texture object will likely need two BaseLevel and MaxLevel attributes. One that's clamped and used locally and the other that simply holds the set value as given by the application in the glTexParameter call. Thoughts? From reading the bug report, it sounds like the ARB decided that clamping should be done when the texture is used, not when glTexParameter is called. In the GL 4.3 spec I don't see any language about clamping in glTexParameter either. We should be doing the use-time clamping already. So I think we just have to remove the clamping step in glTexParameter. -Brian -- Courtney Goeltzenleuchter LunarG ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/9] mesa: Fill out ARB_texture_view entry points
Browsing the code a little, it's not clear that drivers are using the
texture object's BaseLevel in a safe manner.
Some example uses of BaseLevel:
[intel driver]
const struct gl_texture_image *img = t-Image[0][t-BaseLevel]; //
Without conditioning, this could lead to memory access error. Maybe
that's already an issue?
firstImage = tObj-Image[0][tObj-BaseLevel]; // Same with this
if (sampler-MinFilter == GL_NEAREST ||
sampler-MinFilter == GL_LINEAR) {
maxlevel = tObj-BaseLevel;
} else {
maxlevel = tObj-_MaxLevel;
}
[st_atom_sampler]
sampler-min_lod = CLAMP(msamp-MinLod,
0.0f,
(GLfloat) texobj-MaxLevel - texobj-BaseLevel);
There are more. All using the values that were set in TexParam.
Courtney
On Thu, Dec 5, 2013 at 9:41 AM, Courtney Goeltzenleuchter
court...@lunarg.com wrote:
Okay, that makes it easier.
Should this change be conditional based on the type of context created?
Courtney
On Thu, Dec 5, 2013 at 8:52 AM, Brian Paul bri...@vmware.com wrote:
On 12/04/2013 03:46 PM, Courtney Goeltzenleuchter wrote:
It's come to my attention that Mesa's handling of GL_TEXTURE_BASE_LEVEL
and GL_TEXTURE_MAX_LEVEL in glTexParameter and glGetTexParameter may be
incorrect. The issue happens with the following sequence:
glTexStorage2D(GL_TEXTURE_2D, 4, GL_RGBA8, 128, 128);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_BASE_LEVEL, 5);
glGetTexParameter(GL_TEXTURE_2D, GL_TEXTURE_BASE_LEVEL, n);
The key question is: What is the value of n?
Right now, the Mesa driver will clamp the glTexParameter call to the
range 0 .. 3 (as specified by the TexStorage call) and n = 3 after the
GetTexParameter call. However, the value returned on the Intel Windows
driver and NVIDIA's Linux driver return 5. This has apparently been
discussed among Kronos members in bug: 9342
(https://cvs.khronos.org/bugzilla/show_bug.cgi?id=9342
https://urldefense.proofpoint.com/v1/url?u=https:
//cvs.khronos.org/bugzilla/show_bug.cgi?id%3D9342k=
oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%
2BTLs8wadB%2BiIj9xpBY%3D%0Am=SrPAWBW251dxCErQJNhB0m93E9Vb62
KGHxK3yiRBRuU%3D%0As=a0c086b7a31a804e3e786118fd1771
b53c85717a4cf0c8dea41b60e5acd0406b)
which I don't have visibility of.
To match that behavior the texture object will likely need two BaseLevel
and MaxLevel attributes. One that's clamped and used locally and the
other that simply holds the set value as given by the application in the
glTexParameter call.
Thoughts?
From reading the bug report, it sounds like the ARB decided that clamping
should be done when the texture is used, not when glTexParameter is called.
In the GL 4.3 spec I don't see any language about clamping in
glTexParameter either.
We should be doing the use-time clamping already. So I think we just
have to remove the clamping step in glTexParameter.
-Brian
--
Courtney Goeltzenleuchter
LunarG
--
Courtney Goeltzenleuchter
LunarG
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/9] mesa: Fill out ARB_texture_view entry points
In _mesa_test_texobj_completeness() we check if BaseLevel is negative.
If so, we mark the texture object as 'incomplete'. Down in the drivers,
we should never sample from a texture that's incomplete. In gallium,
for example, we use a dummy/fallback texture instead.
-Brian
On 12/05/2013 10:16 AM, Courtney Goeltzenleuchter wrote:
Browsing the code a little, it's not clear that drivers are using the
texture object's BaseLevel in a safe manner.
Some example uses of BaseLevel:
[intel driver]
const struct gl_texture_image *img = t-Image[0][t-BaseLevel]; //
Without conditioning, this could lead to memory access error. Maybe that's already an
issue?
firstImage = tObj-Image[0][tObj-BaseLevel]; // Same with this
if (sampler-MinFilter == GL_NEAREST ||
sampler-MinFilter == GL_LINEAR) {
maxlevel = tObj-BaseLevel;
}else{
maxlevel=tObj-_MaxLevel;
}
[st_atom_sampler]
sampler-min_lod = CLAMP(msamp-MinLod,
0.0f,
(GLfloat) texobj-MaxLevel -
texobj-BaseLevel);
There are more. All using the values that were set in TexParam.
Courtney
On Thu, Dec 5, 2013 at 9:41 AM, Courtney Goeltzenleuchter
court...@lunarg.com mailto:court...@lunarg.com wrote:
Okay, that makes it easier.
Should this change be conditional based on the type of context created?
Courtney
On Thu, Dec 5, 2013 at 8:52 AM, Brian Paul bri...@vmware.com
mailto:bri...@vmware.com wrote:
On 12/04/2013 03:46 PM, Courtney Goeltzenleuchter wrote:
It's come to my attention that Mesa's handling of
GL_TEXTURE_BASE_LEVEL
and GL_TEXTURE_MAX_LEVEL in glTexParameter and
glGetTexParameter may be
incorrect. The issue happens with the following sequence:
glTexStorage2D(GL_TEXTURE_2D, 4, GL_RGBA8, 128, 128);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_BASE_LEVEL, 5);
glGetTexParameter(GL_TEXTURE___2D, GL_TEXTURE_BASE_LEVEL, n);
The key question is: What is the value of n?
Right now, the Mesa driver will clamp the glTexParameter
call to the
range 0 .. 3 (as specified by the TexStorage call) and n = 3
after the
GetTexParameter call. However, the value returned on the
Intel Windows
driver and NVIDIA's Linux driver return 5. This has
apparently been
discussed among Kronos members in bug: 9342
(https://cvs.khronos.org/__bugzilla/show_bug.cgi?id=9342
https://urldefense.proofpoint.com/v1/url?u=https://cvs.khronos.org/bugzilla/show_bug.cgi?id%3D9342k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=8j9s5ig%2FDyFT8SNxc8Hh2Ote4QS96m9F38JN6bYow4U%3D%0As=8b560a97e6e9d96f301fa9015d729022dfa73f3f26427740d8cd54d2e29e76c1
https://urldefense.__proofpoint.com/v1/url?u=https:__//cvs.khronos.org/bugzilla/__show_bug.cgi?id%3D9342k=__oIvRg1%2BdGAgOoM1BIlLLqw%3D%__3D%0Ar=__lGQMzzTgII0I7jefp2FHq7WtZ%__2BTLs8wadB%2BiIj9xpBY%3D%0Am=__SrPAWBW251dxCErQJNhB0m93E9Vb62__KGHxK3yiRBRuU%3D%0As=__a0c086b7a31a804e3e786118fd1771__b53c85717a4cf0c8dea41b60e5acd0__406b
https://urldefense.proofpoint.com/v1/url?u=https://cvs.khronos.org/bugzilla/show_bug.cgi?id%3D9342k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=SrPAWBW251dxCErQJNhB0m93E9Vb62KGHxK3yiRBRuU%3D%0As=a0c086b7a31a804e3e786118fd1771b53c85717a4cf0c8dea41b60e5acd0406b)
which I don't have visibility of.
To match that behavior the texture object will likely need
two BaseLevel
and MaxLevel attributes. One that's clamped and used locally
and the
other that simply holds the set value as given by the
application in the
glTexParameter call.
Thoughts?
From reading the bug report, it sounds like the ARB decided
that clamping should be done when the texture is used, not when
glTexParameter is called. In the GL 4.3 spec I don't see any
language about clamping in glTexParameter either.
We should be doing the use-time clamping already. So I think we
just have to remove the clamping step in glTexParameter.
-Brian
--
Courtney Goeltzenleuchter
LunarG
--
Courtney Goeltzenleuchter
LunarG
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/9] mesa: Fill out ARB_texture_view entry points
It's come to my attention that Mesa's handling of GL_TEXTURE_BASE_LEVEL and GL_TEXTURE_MAX_LEVEL in glTexParameter and glGetTexParameter may be incorrect. The issue happens with the following sequence: glTexStorage2D(GL_TEXTURE_2D, 4, GL_RGBA8, 128, 128); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_BASE_LEVEL, 5); glGetTexParameter(GL_TEXTURE_2D, GL_TEXTURE_BASE_LEVEL, n); The key question is: What is the value of n? Right now, the Mesa driver will clamp the glTexParameter call to the range 0 .. 3 (as specified by the TexStorage call) and n = 3 after the GetTexParameter call. However, the value returned on the Intel Windows driver and NVIDIA's Linux driver return 5. This has apparently been discussed among Kronos members in bug: 9342 ( https://cvs.khronos.org/bugzilla/show_bug.cgi?id=9342) which I don't have visibility of. To match that behavior the texture object will likely need two BaseLevel and MaxLevel attributes. One that's clamped and used locally and the other that simply holds the set value as given by the application in the glTexParameter call. Thoughts? Courtney On Tue, Dec 3, 2013 at 4:30 PM, Courtney Goeltzenleuchter court...@lunarg.com wrote: On Tue, Dec 3, 2013 at 4:28 PM, Brian Paul bri...@vmware.com wrote: On 12/03/2013 02:56 PM, Courtney Goeltzenleuchter wrote: Hi Brian, I've made all the recommended changes. I also added one, a test that the Driver.TextureView != NULL before calling. This lets me test the non DD functionality with the MESA_EXTENSION_OVERRIDE=+GL_ARB_texture_view I've also rebased to latest master (no changes required). Whole stream can be found at: https://github.com/courtney-lunarg/mesa/tree/texture_view-rc6 https://urldefense.proofpoint.com/v1/url?u=https: //github.com/courtney-lunarg/mesa/tree/texture_view-rc6k= oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ% 2BTLs8wadB%2BiIj9xpBY%3D%0Am=StSJ4O%2Fa%2B9Zp%2FeTtJIDzJ1NxrKtDXrENaO% 2FoFA9gY1k%3D%0As=0439e3fc50d195734c13b4c5e22024 f034c27b7e657c8f79e08993b98f117518 Let me know if you need me to post the patches to the mail list or not. The series LGTM. Thanks. Reviewed-by: Brian Paul bri...@vmware.com Do you need someone to push to master for you? Yes please! -Brian -- Courtney Goeltzenleuchter LunarG -- Courtney Goeltzenleuchter LunarG ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/9] mesa: Fill out ARB_texture_view entry points
This looks pretty good. Just a bunch of nitpicks below.
On 11/25/2013 05:49 PM, Courtney Goeltzenleuchter wrote:
Add Mesa TextureView logic.
Incorporate feedback on ARB_texture_view:
- Add S3TC VIEW_CLASSes to compatibility table
- Use existing _mesa_get_tex_image
- Clean up error strings
- Use bool instead of GLboolean for internal functions
- Split compound level layer test into individual tests
Signed-off-by: Courtney Goeltzenleuchter court...@lunarg.com
---
src/mesa/main/textureview.c | 540 +++-
1 file changed, 539 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/textureview.c b/src/mesa/main/textureview.c
index 4a6bd62..1bfc86b 100644
--- a/src/mesa/main/textureview.c
+++ b/src/mesa/main/textureview.c
@@ -38,10 +38,318 @@
#include macros.h
#include teximage.h
#include texobj.h
+#include mipmap.h
#include texstorage.h
#include textureview.h
+#include stdbool.h
#include mtypes.h
+/* Table 3.X.2 (Compatible internal formats for TextureView)
+---
+| Class | Internal formats|
+---
+| VIEW_CLASS_128_BITS | RGBA32F, RGBA32UI, RGBA32I |
+---
+| VIEW_CLASS_96_BITS| RGB32F, RGB32UI, RGB32I |
+---
+| VIEW_CLASS_64_BITS| RGBA16F, RG32F, RGBA16UI, RG32UI, RGBA16I, |
+| | RG32I, RGBA16, RGBA16_SNORM |
+---
+| VIEW_CLASS_48_BITS| RGB16, RGB16_SNORM, RGB16F, RGB16UI, RGB16I |
+---
+| VIEW_CLASS_32_BITS| RG16F, R11F_G11F_B10F, R32F,|
+| | RGB10_A2UI, RGBA8UI, RG16UI, R32UI, |
+| | RGBA8I, RG16I, R32I, RGB10_A2, RGBA8, RG16, |
+| | RGBA8_SNORM, RG16_SNORM, SRGB8_ALPHA8, RGB9_E5 |
+---
+| VIEW_CLASS_24_BITS| RGB8, RGB8_SNORM, SRGB8, RGB8UI, RGB8I |
+---
+| VIEW_CLASS_16_BITS| R16F, RG8UI, R16UI, RG8I, R16I, RG8, R16, |
+| | RG8_SNORM, R16_SNORM|
+---
+| VIEW_CLASS_8_BITS | R8UI, R8I, R8, R8_SNORM |
+---
+| VIEW_CLASS_RGTC1_RED | COMPRESSED_RED_RGTC1, |
+| | COMPRESSED_SIGNED_RED_RGTC1 |
+---
+| VIEW_CLASS_RGTC2_RG | COMPRESSED_RG_RGTC2,|
+| | COMPRESSED_SIGNED_RG_RGTC2 |
+---
+| VIEW_CLASS_BPTC_UNORM | COMPRESSED_RGBA_BPTC_UNORM, |
+| | COMPRESSED_SRGB_ALPHA_BPTC_UNORM|
+---
+| VIEW_CLASS_BPTC_FLOAT | COMPRESSED_RGB_BPTC_SIGNED_FLOAT, |
+| | COMPRESSED_RGB_BPTC_UNSIGNED_FLOAT |
+---
+ */
+struct internal_format_class_info {
+ GLenum view_class;
+ GLenum internal_format;
+};
+#define INFO(c,f) {GL_##c, GL_##f}
I'd like to see this INFO() macro stuff go away. It just obfuscates the
code.
+static const struct internal_format_class_info compatible_internal_formats[] =
{
+ INFO(VIEW_CLASS_128_BITS, RGBA32F),
+ INFO(VIEW_CLASS_128_BITS, RGBA32UI),
+ INFO(VIEW_CLASS_128_BITS, RGBA32I),
+ INFO(VIEW_CLASS_96_BITS, RGB32F),
+ INFO(VIEW_CLASS_96_BITS, RGB32UI),
+ INFO(VIEW_CLASS_96_BITS, RGB32I),
+ INFO(VIEW_CLASS_64_BITS, RGBA16F),
+ INFO(VIEW_CLASS_64_BITS, RG32F),
+ INFO(VIEW_CLASS_64_BITS, RGBA16UI),
+ INFO(VIEW_CLASS_64_BITS, RG32UI),
+ INFO(VIEW_CLASS_64_BITS, RGBA16I),
+ INFO(VIEW_CLASS_64_BITS, RG32I),
+ INFO(VIEW_CLASS_64_BITS, RGBA16),
+ INFO(VIEW_CLASS_64_BITS, RGBA16_SNORM),
+ INFO(VIEW_CLASS_48_BITS, RGB16),
+ INFO(VIEW_CLASS_48_BITS, RGB16_SNORM),
+ INFO(VIEW_CLASS_48_BITS, RGB16F),
+ INFO(VIEW_CLASS_48_BITS, RGB16UI),
+ INFO(VIEW_CLASS_48_BITS, RGB16I),
+
Re: [Mesa-dev] [PATCH 7/9] mesa: Fill out ARB_texture_view entry points
On Tue, Nov 26, 2013 at 3:59 PM, Courtney Goeltzenleuchter court...@lunarg.com wrote: With these changes, what needs to happen to commit these changes to master? I'd like to do another quick review but I'm on vacation this week and not finding much time for email/reviewing. Maybe in a few days. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/9] mesa: Fill out ARB_texture_view entry points
With these changes, what needs to happen to commit these changes to master? Thanks, Courtney On Mon, Nov 25, 2013 at 6:01 PM, Courtney Goeltzenleuchter court...@lunarg.com wrote: While incorporating Brian's comments I did some refactoring to consolidate multiple uses of next_mimap_level_size into one shared helper function. That adds another commit to the stream. I thought it was big enough now that I should post the branch to make it easier to use. I've posted the updated stream, including the next_mipmap_level_size refactoring on github here: https://github.com/courtney-lunarg/mesa/tree/texture_view-rc5 Courtney -- Courtney Goeltzenleuchter LunarG -- Courtney Goeltzenleuchter LunarG ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 7/9] mesa: Fill out ARB_texture_view entry points
Add Mesa TextureView logic.
Incorporate feedback on ARB_texture_view:
- Add S3TC VIEW_CLASSes to compatibility table
- Use existing _mesa_get_tex_image
- Clean up error strings
- Use bool instead of GLboolean for internal functions
- Split compound level layer test into individual tests
Signed-off-by: Courtney Goeltzenleuchter court...@lunarg.com
---
src/mesa/main/textureview.c | 540 +++-
1 file changed, 539 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/textureview.c b/src/mesa/main/textureview.c
index 4a6bd62..1bfc86b 100644
--- a/src/mesa/main/textureview.c
+++ b/src/mesa/main/textureview.c
@@ -38,10 +38,318 @@
#include macros.h
#include teximage.h
#include texobj.h
+#include mipmap.h
#include texstorage.h
#include textureview.h
+#include stdbool.h
#include mtypes.h
+/* Table 3.X.2 (Compatible internal formats for TextureView)
+---
+| Class | Internal formats|
+---
+| VIEW_CLASS_128_BITS | RGBA32F, RGBA32UI, RGBA32I |
+---
+| VIEW_CLASS_96_BITS| RGB32F, RGB32UI, RGB32I |
+---
+| VIEW_CLASS_64_BITS| RGBA16F, RG32F, RGBA16UI, RG32UI, RGBA16I, |
+| | RG32I, RGBA16, RGBA16_SNORM |
+---
+| VIEW_CLASS_48_BITS| RGB16, RGB16_SNORM, RGB16F, RGB16UI, RGB16I |
+---
+| VIEW_CLASS_32_BITS| RG16F, R11F_G11F_B10F, R32F,|
+| | RGB10_A2UI, RGBA8UI, RG16UI, R32UI, |
+| | RGBA8I, RG16I, R32I, RGB10_A2, RGBA8, RG16, |
+| | RGBA8_SNORM, RG16_SNORM, SRGB8_ALPHA8, RGB9_E5 |
+---
+| VIEW_CLASS_24_BITS| RGB8, RGB8_SNORM, SRGB8, RGB8UI, RGB8I |
+---
+| VIEW_CLASS_16_BITS| R16F, RG8UI, R16UI, RG8I, R16I, RG8, R16, |
+| | RG8_SNORM, R16_SNORM|
+---
+| VIEW_CLASS_8_BITS | R8UI, R8I, R8, R8_SNORM |
+---
+| VIEW_CLASS_RGTC1_RED | COMPRESSED_RED_RGTC1, |
+| | COMPRESSED_SIGNED_RED_RGTC1 |
+---
+| VIEW_CLASS_RGTC2_RG | COMPRESSED_RG_RGTC2,|
+| | COMPRESSED_SIGNED_RG_RGTC2 |
+---
+| VIEW_CLASS_BPTC_UNORM | COMPRESSED_RGBA_BPTC_UNORM, |
+| | COMPRESSED_SRGB_ALPHA_BPTC_UNORM|
+---
+| VIEW_CLASS_BPTC_FLOAT | COMPRESSED_RGB_BPTC_SIGNED_FLOAT, |
+| | COMPRESSED_RGB_BPTC_UNSIGNED_FLOAT |
+---
+ */
+struct internal_format_class_info {
+ GLenum view_class;
+ GLenum internal_format;
+};
+#define INFO(c,f) {GL_##c, GL_##f}
+static const struct internal_format_class_info compatible_internal_formats[] =
{
+ INFO(VIEW_CLASS_128_BITS, RGBA32F),
+ INFO(VIEW_CLASS_128_BITS, RGBA32UI),
+ INFO(VIEW_CLASS_128_BITS, RGBA32I),
+ INFO(VIEW_CLASS_96_BITS, RGB32F),
+ INFO(VIEW_CLASS_96_BITS, RGB32UI),
+ INFO(VIEW_CLASS_96_BITS, RGB32I),
+ INFO(VIEW_CLASS_64_BITS, RGBA16F),
+ INFO(VIEW_CLASS_64_BITS, RG32F),
+ INFO(VIEW_CLASS_64_BITS, RGBA16UI),
+ INFO(VIEW_CLASS_64_BITS, RG32UI),
+ INFO(VIEW_CLASS_64_BITS, RGBA16I),
+ INFO(VIEW_CLASS_64_BITS, RG32I),
+ INFO(VIEW_CLASS_64_BITS, RGBA16),
+ INFO(VIEW_CLASS_64_BITS, RGBA16_SNORM),
+ INFO(VIEW_CLASS_48_BITS, RGB16),
+ INFO(VIEW_CLASS_48_BITS, RGB16_SNORM),
+ INFO(VIEW_CLASS_48_BITS, RGB16F),
+ INFO(VIEW_CLASS_48_BITS, RGB16UI),
+ INFO(VIEW_CLASS_48_BITS, RGB16I),
+ INFO(VIEW_CLASS_32_BITS, RG16F),
+ INFO(VIEW_CLASS_32_BITS, R11F_G11F_B10F),
+ INFO(VIEW_CLASS_32_BITS, R32F),
+ INFO(VIEW_CLASS_32_BITS, RGB10_A2UI),
+ INFO(VIEW_CLASS_32_BITS, RGBA8UI),
+
Re: [Mesa-dev] [PATCH 7/9] mesa: Fill out ARB_texture_view entry points
While incorporating Brian's comments I did some refactoring to consolidate multiple uses of next_mimap_level_size into one shared helper function. That adds another commit to the stream. I thought it was big enough now that I should post the branch to make it easier to use. I've posted the updated stream, including the next_mipmap_level_size refactoring on github here: https://github.com/courtney-lunarg/mesa/tree/texture_view-rc5 Courtney -- Courtney Goeltzenleuchter LunarG ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
