[Mesa-dev] [v2 1/2] meta/blit: Add stencil texturing mode save and restore
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
Cc: 10.2 mesa-sta...@lists.freedesktop.org
v2 (Ken): Only restore the mode if it has changed.
---
src/mesa/drivers/common/meta.h | 4 ++--
src/mesa/drivers/common/meta_blit.c | 13 -
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/common/meta.h b/src/mesa/drivers/common/meta.h
index 007f104..765f8df 100644
--- a/src/mesa/drivers/common/meta.h
+++ b/src/mesa/drivers/common/meta.h
@@ -270,7 +270,7 @@ struct blit_state
struct fb_tex_blit_state
{
GLint baseLevelSave, maxLevelSave;
- GLuint sampler, samplerSave;
+ GLuint sampler, samplerSave, stencilSamplingSave;
GLuint tempTex;
};
@@ -407,7 +407,7 @@ _mesa_meta_fb_tex_blit_begin(const struct gl_context *ctx,
struct fb_tex_blit_state *blit);
extern void
-_mesa_meta_fb_tex_blit_end(const struct gl_context *ctx, GLenum target,
+_mesa_meta_fb_tex_blit_end(struct gl_context *ctx, GLenum target,
struct fb_tex_blit_state *blit);
extern GLboolean
diff --git a/src/mesa/drivers/common/meta_blit.c
b/src/mesa/drivers/common/meta_blit.c
index e10a181..b733fd3 100644
--- a/src/mesa/drivers/common/meta_blit.c
+++ b/src/mesa/drivers/common/meta_blit.c
@@ -441,6 +441,7 @@ blitframebuffer_texture(struct gl_context *ctx,
fb_tex_blit.baseLevelSave = texObj-BaseLevel;
fb_tex_blit.maxLevelSave = texObj-MaxLevel;
+ fb_tex_blit.stencilSamplingSave = texObj-StencilSampling;
if (glsl_version) {
setup_glsl_blit_framebuffer(ctx, blit, rb, target);
@@ -567,7 +568,7 @@ _mesa_meta_fb_tex_blit_begin(const struct gl_context *ctx,
}
void
-_mesa_meta_fb_tex_blit_end(const struct gl_context *ctx, GLenum target,
+_mesa_meta_fb_tex_blit_end(struct gl_context *ctx, GLenum target,
struct fb_tex_blit_state *blit)
{
/* Restore texture object state, the texture binding will
@@ -576,6 +577,16 @@ _mesa_meta_fb_tex_blit_end(const struct gl_context *ctx,
GLenum target,
if (target != GL_TEXTURE_RECTANGLE_ARB) {
_mesa_TexParameteri(target, GL_TEXTURE_BASE_LEVEL, blit-baseLevelSave);
_mesa_TexParameteri(target, GL_TEXTURE_MAX_LEVEL, blit-maxLevelSave);
+
+ if (ctx-Extensions.ARB_stencil_texturing) {
+ const struct gl_texture_object *texObj =
+_mesa_get_current_tex_object(ctx, target);
+
+ if (texObj-StencilSampling != blit-stencilSamplingSave)
+_mesa_TexParameteri(target, GL_DEPTH_STENCIL_TEXTURE_MODE,
+blit-stencilSamplingSave ?
+ GL_STENCIL_INDEX : GL_DEPTH_COMPONENT);
+ }
}
_mesa_BindSampler(ctx-Texture.CurrentUnit, blit-samplerSave);
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] meta/blit: Add stencil texturing mode save and restore
On Wed, May 21, 2014 at 01:47:05PM -0700, Eric Anholt wrote:
Pohjolainen, Topi topi.pohjolai...@intel.com writes:
On Wed, May 21, 2014 at 12:51:07PM -0700, Eric Anholt wrote:
Pohjolainen, Topi topi.pohjolai...@intel.com writes:
On Wed, May 21, 2014 at 09:41:39PM +0300, Pohjolainen, Topi wrote:
On Wed, May 21, 2014 at 09:37:30PM +0300, Pohjolainen, Topi wrote:
On Wed, May 21, 2014 at 11:29:02AM -0700, Eric Anholt wrote:
Topi Pohjolainen topi.pohjolai...@intel.com writes:
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
Cc: 10.2 mesa-sta...@lists.freedesktop.org
---
src/mesa/drivers/common/meta.h | 4 ++--
src/mesa/drivers/common/meta_blit.c | 15 ++-
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/common/meta.h
b/src/mesa/drivers/common/meta.h
index 007f104..765f8df 100644
--- a/src/mesa/drivers/common/meta.h
+++ b/src/mesa/drivers/common/meta.h
@@ -270,7 +270,7 @@ struct blit_state
struct fb_tex_blit_state
{
GLint baseLevelSave, maxLevelSave;
- GLuint sampler, samplerSave;
+ GLuint sampler, samplerSave, stencilSamplingSave;
GLuint tempTex;
};
@@ -407,7 +407,7 @@ _mesa_meta_fb_tex_blit_begin(const struct
gl_context *ctx,
struct fb_tex_blit_state *blit);
extern void
-_mesa_meta_fb_tex_blit_end(const struct gl_context *ctx, GLenum
target,
+_mesa_meta_fb_tex_blit_end(struct gl_context *ctx, GLenum target,
struct fb_tex_blit_state *blit);
extern GLboolean
diff --git a/src/mesa/drivers/common/meta_blit.c
b/src/mesa/drivers/common/meta_blit.c
index e10a181..59f7e70 100644
--- a/src/mesa/drivers/common/meta_blit.c
+++ b/src/mesa/drivers/common/meta_blit.c
@@ -441,6 +441,7 @@ blitframebuffer_texture(struct gl_context
*ctx,
fb_tex_blit.baseLevelSave = texObj-BaseLevel;
fb_tex_blit.maxLevelSave = texObj-MaxLevel;
+ fb_tex_blit.stencilSamplingSave = texObj-StencilSampling;
if (glsl_version) {
setup_glsl_blit_framebuffer(ctx, blit, rb, target);
@@ -567,7 +568,7 @@ _mesa_meta_fb_tex_blit_begin(const struct
gl_context *ctx,
}
void
-_mesa_meta_fb_tex_blit_end(const struct gl_context *ctx, GLenum
target,
+_mesa_meta_fb_tex_blit_end(struct gl_context *ctx, GLenum target,
struct fb_tex_blit_state *blit)
{
/* Restore texture object state, the texture binding will
@@ -576,6 +577,18 @@ _mesa_meta_fb_tex_blit_end(const struct
gl_context *ctx, GLenum target,
if (target != GL_TEXTURE_RECTANGLE_ARB) {
_mesa_TexParameteri(target, GL_TEXTURE_BASE_LEVEL,
blit-baseLevelSave);
_mesa_TexParameteri(target, GL_TEXTURE_MAX_LEVEL,
blit-maxLevelSave);
+
+ if (ctx-Extensions.ARB_stencil_texturing) {
+ struct gl_texture_object *texObj =
+_mesa_get_current_tex_object(ctx, target);
+
+ /* One cannot use _mesa_TexParameteri() in case the
stencil indexing
+ * wasn't modified during the blit. Hence write the
saved value
+ * directly.
+ */
Can you explain that some more? I'm uncomfortable with direct
modification of the values instead of _mesa_TexParameteri, becuase
it
means that any other state update handling (like making sure that
the
call to Driver.TexParameter() has happened, or any necessary
flushes)
isn't getting done.
Glad to, if the mode was 'GL_DEPTH_COMPONENT' originally and the blit
doesn't
modify it than the following issues an error:
That doesn't make sense afterall, let me check again which error I hit.
Right, the value can originally be invalid, I have simply zero in one of
the
runs. So it looks that proper solution is to check in addition to the
stencil extension being supported that the original value was valid. And
only
then try to restore. Does that sound right?
Sounds like it's time to track down why the original value was invalid,
and fix it.
So I take it that any normal RGBA texture should have either
GL_DEPTH_COMPONENT
or GL_STENCIL_INDEX as the value for the stencil texturing mode even if
neither is really applicable?
The ARB_stencil_texturing.txt says the default value is
GL_DEPTH_COMPONENT -- we should probably have a test for
glGetTexParameteri on the parameter on a normal RGBA texture.
Thanks for explaining this. Ken has a proper solution for the restoring here
I think (just sent as version 2). How about I'll add this in the list of my
Re: [Mesa-dev] [PATCH] gallium: reflect likely outcome in execution flow
On Wed, 2014-05-21 at 18:05 -0400, Ilia Mirkin wrote: On Wed, May 21, 2014 at 6:02 PM, Timothy Arceri t_arc...@yahoo.com.au wrote: Unless we run out of memory the old if statement would always fail so reflect the more likely outcome. Should be be faster most of the time and slightly cleaner looking code. Signed-off-by: Timothy Arceri t_arc...@yahoo.com.au --- src/gallium/auxiliary/util/u_upload_mgr.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/src/gallium/auxiliary/util/u_upload_mgr.c b/src/gallium/auxiliary/util/u_upload_mgr.c index 744ea2e..99f9a08 100644 --- a/src/gallium/auxiliary/util/u_upload_mgr.c +++ b/src/gallium/auxiliary/util/u_upload_mgr.c @@ -247,11 +247,10 @@ enum pipe_error u_upload_data( struct u_upload_mgr *upload, enum pipe_error ret = u_upload_alloc(upload, min_out_offset, size, out_offset, outbuf, (void**)ptr); - if (ret != PIPE_OK) - return ret; + if (ret == PIPE_OK) + memcpy(ptr, data, size); - memcpy(ptr, data, size); - return PIPE_OK; + return ret; } Have you actually compared the generated code? I find it can be fairly instructive to do so... btw, there's a likely() (and unlikely() ) primitive (in p_compiler.h) which will indicate to gcc whether a particular condition is likely or unlikely, so that it can adjust its code generation accordingly. -ilia Hi Ilia, I've taken a look at the results (see below) and read up on likely/unlikely (I was aware of these but wasn't confident in when they should be used). The result is my patch avoids a jump which I assume should help with branch prediction in the cpu? Something like this is what I was expecting with the change. The interesting thing is that in this case using likely seems to have added an extra 'test' instruction for no added value (please correct me if I'm wrong). However there is probably other places in u_upload_alloc(), etc where likely might be more helpful. Tim Common code: 444fce: 55 push %rbp 444fcf: 48 89 e5mov%rsp,%rbp 444fd2: 48 83 ec 40 sub$0x40,%rsp 444fd6: 48 89 7d e8 mov%rdi,-0x18(%rbp) 444fda: 89 75 e4mov%esi,-0x1c(%rbp) 444fdd: 89 55 e0mov%edx,-0x20(%rbp) 444fe0: 48 89 4d d8 mov%rcx,-0x28(%rbp) 444fe4: 4c 89 45 d0 mov%r8,-0x30(%rbp) 444fe8: 4c 89 4d c8 mov%r9,-0x38(%rbp) 444fec: 4c 8d 45 f0 lea-0x10(%rbp),%r8 444ff0: 48 8b 7d c8 mov-0x38(%rbp),%rdi 444ff4: 48 8b 4d d0 mov-0x30(%rbp),%rcx 444ff8: 8b 55 e0mov-0x20(%rbp),%edx 444ffb: 8b 75 e4mov-0x1c(%rbp),%esi 444ffe: 48 8b 45 e8 mov-0x18(%rbp),%rax 445002: 4d 89 c1mov%r8,%r9 445005: 49 89 f8mov%rdi,%r8 445008: 48 89 c7mov%rax,%rdi 44500b: e8 78 fd ff ff callq 444d88 u_upload_alloc 445010: 89 45 fcmov%eax,-0x4(%rbp) 445013: 83 7d fc 00 cmpl $0x0,-0x4(%rbp) Pre change: 00444fce u_upload_data: 445017: 74 05 je 44501e u_upload_data+0x50 445019: 8b 45 fcmov-0x4(%rbp),%eax 44501c: eb 1b jmp445039 u_upload_data+0x6b 44501e: 8b 55 e0mov-0x20(%rbp),%edx 445021: 48 8b 45 f0 mov-0x10(%rbp),%rax 445025: 48 8b 4d d8 mov-0x28(%rbp),%rcx 445029: 48 89 cemov%rcx,%rsi 44502c: 48 89 c7mov%rax,%rdi 44502f: e8 2c 40 c0 ff callq 49060 memcpy@plt 445034: b8 00 00 00 00 mov$0x0,%eax 445039: c9 leaveq 44503a: c3 retq Post change: 00444fce u_upload_data: 445017: 75 16 jne44502f u_upload_data+0x61 445019: 8b 55 e0mov-0x20(%rbp),%edx 44501c: 48 8b 45 f0 mov-0x10(%rbp),%rax 445020: 48 8b 4d d8 mov-0x28(%rbp),%rcx 445024: 48 89 cemov%rcx,%rsi 445027: 48 89 c7mov%rax,%rdi 44502a: e8 31 40 c0 ff callq 49060 memcpy@plt 44502f: 8b 45 fcmov-0x4(%rbp),%eax 445032: c9 leaveq 445033: c3 retq With likely: 00444fce u_upload_data: 44501d: 48 85 c0test %rax,%rax 445020: 74 16 je 445038
[Mesa-dev] [Bug 77161] [softpipe] piglit fbo-generatemipmap-cubemap S3TC_DXT1 regression
https://bugs.freedesktop.org/show_bug.cgi?id=77161 --- Comment #4 from Roland Scheidegger srol...@vmware.com --- Oh I forgot that ARB_texture_view also allows you to do that. All the more reason to allow it in gallium (and use for cube map mip generation). -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] i965: Adding comments and cleaning up push/pull constants
On Wed, 2014-05-21 at 15:04 -0700, Eric Anholt wrote: Since I'm leaving Intel in a couple weeks, Hi Eric, If you don't mind me asking where are you off to? Will you still be working on Mesa? Or are you changing things up? Either way, good luck. I figured the best thing I could do for the driver in that time would be to take a pass over the whole codebase and braindump into the comments. I didn't make it very far without finding a lot of silly code that ought to be cleaned up, so I went ahead and did that. This code sits on top of the CURBE cleanups I sent out, and can be found in the comments branch of my tree. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 79016] [REGRESSION] st/mesa: drop the lowering of quad strips to triangle strips
https://bugs.freedesktop.org/show_bug.cgi?id=79016
--- Comment #6 from Maarten Lankhorst b...@mblankhorst.nl ---
Probe at (48,66)
Expected: 0.423529 0.011765 0.313726 0.501961
Observed: 0.501961 0.125490 0.125490 0.501961
PIGLIT: {'result': 'warn' }
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/12] gallivm: Use LLVM global context.
Hi Mathias, Sorry for the delay. - Original Message - Hi Jose, I tried to get my local llvm install again to a point where I can see backtrace information, but still failed to get valgrind/massif to print these nice backtraces. All of the llvm addresses are not resolved so far. But a appart from that which gl example/test program do you run to see that leakage? This was with some internal code (it was not even GL.) But I've distilled the test case to its core essence. It is in this git repos git clone git://people.freedesktop.org/~jrfonseca/llvm-jitstress It's really simple to use. If you follow the instructions there you'll be able easily to repro the problem and see precisely the same stack traces. There's still some tweaks I want to do, but I hope to get this upstreamed into LLVM eventually. And additionally looking at this below backtrace snippet and analyzing the code that is called in llvm: On Wednesday, May 14, 2014 02:45:26 you wrote: The problem is that when I do this, memory starts leaking for every compilation (even with LLVM 3.4): - 100.00% (672B): operator new(unsigned long) - 100.00% (672B): std::_Rb_treellvm::EVT, llvm::EVT, std::_Identityllvm::EVT, llvm::EVT::compareRawBits, std::allocatorllvm::EVT ::_M_insert_unique(llvm::EVT const) - 100.00% (672B): llvm::SDNode::getValueTypeList(llvm::EVT) - 100.00% (672B): llvm::SelectionDAG::getVTList(llvm::EVT) Ok, I see, this std::set in ./lib/CodeGen/SelectionDAG/SelectionDAG.cpp holds EVT instances which have a possible pointer to llvm::Type objects declared in llvm/IR/Type.h. And such a Type seems to reference a LLVMContext with the 'Context' member in llvm::Type. Since the std::setEVT, ...'s less operator treats EVT's to equivalent EVT's referencing llvm::Types originating from different LLVMContext instances differently, this grows with the LLVMContext instances around. Ok, a correct solution inside llvm would be to prune these set entries once the LLVMContext dies. A workaround from our side could probably be to have a LLVMContext private to the GL context as already suggested. That would still grow with the number of GL contexts. Yes, I think that's a great idea. In short, besides the existing gallivm_context (which is actually not per context, but rather per module/ compilation unit) there should be a new object, that's truly per context, that holds two things: - LLVMContextRef - src/gallium/auxiliary/gallivm/lp_bld_misc.cpp's ShaderMemoryManager. Each draw_context and llvmpipe_context should one of these (it's fine not to share the same. The existing gallivm_context should probably be renamed gallivm_module. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 79016] [REGRESSION] st/mesa: drop the lowering of quad strips to triangle strips
https://bugs.freedesktop.org/show_bug.cgi?id=79016 Marek Olšák mar...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #7 from Marek Olšák mar...@gmail.com --- warn is not a failure, like I said. I knew about this pass-warn change. It actually uncovers a potential issue with the hardware - or with the test. It depends on how you look at it. From the test: * Note: some OpenGL implementations do not pass the flat_first and * flat_last tests when rendering quads or polygons. That is, they * produce a tessellation which contains the correct vertices, but not * in the order required to preserve flat shaded colors. This is * unlikely to cause problems for client programs, since client * programs that use new features like transform feedback are unlikely * to also use deprecated features like quads and polygons. Also, it * is a matter of interpretation whether these tests are expected to * pass at all--after all, the spec does say that the order of * tessellation within a primitive is undefined. Accordingly, these * failures, should they occur, are flagged as warnings rather than * failures. However, my Mesa commit which causes this test not to pass on nouveau, radeon, and probably other gallium drivers, and I did know about this, actually fixes real issues with flat shading and primitive restart and therefore cannot be reverted. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: reflect likely outcome in execution flow
On Thu, May 22, 2014 at 2:56 AM, Timothy Arceri t_arc...@yahoo.com.au wrote: On Wed, 2014-05-21 at 18:05 -0400, Ilia Mirkin wrote: On Wed, May 21, 2014 at 6:02 PM, Timothy Arceri t_arc...@yahoo.com.au wrote: Unless we run out of memory the old if statement would always fail so reflect the more likely outcome. Should be be faster most of the time and slightly cleaner looking code. Signed-off-by: Timothy Arceri t_arc...@yahoo.com.au --- src/gallium/auxiliary/util/u_upload_mgr.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/src/gallium/auxiliary/util/u_upload_mgr.c b/src/gallium/auxiliary/util/u_upload_mgr.c index 744ea2e..99f9a08 100644 --- a/src/gallium/auxiliary/util/u_upload_mgr.c +++ b/src/gallium/auxiliary/util/u_upload_mgr.c @@ -247,11 +247,10 @@ enum pipe_error u_upload_data( struct u_upload_mgr *upload, enum pipe_error ret = u_upload_alloc(upload, min_out_offset, size, out_offset, outbuf, (void**)ptr); - if (ret != PIPE_OK) - return ret; + if (ret == PIPE_OK) + memcpy(ptr, data, size); - memcpy(ptr, data, size); - return PIPE_OK; + return ret; } Have you actually compared the generated code? I find it can be fairly instructive to do so... btw, there's a likely() (and unlikely() ) primitive (in p_compiler.h) which will indicate to gcc whether a particular condition is likely or unlikely, so that it can adjust its code generation accordingly. -ilia Hi Ilia, I've taken a look at the results (see below) and read up on likely/unlikely (I was aware of these but wasn't confident in when they should be used). The result is my patch avoids a jump which I assume should help with branch prediction in the cpu? Something like this is what I was expecting with the change. The interesting thing is that in this case using likely seems to have added an extra 'test' instruction for no added value (please correct me if I'm wrong). However there is probably other places in u_upload_alloc(), etc where likely might be more helpful. Tim Common code: 444fce: 55 push %rbp 444fcf: 48 89 e5 mov%rsp,%rbp 444fd2: 48 83 ec 40 sub$0x40,%rsp 444fd6: 48 89 7d e8 mov%rdi,-0x18(%rbp) 444fda: 89 75 e4 mov%esi,-0x1c(%rbp) 444fdd: 89 55 e0 mov%edx,-0x20(%rbp) 444fe0: 48 89 4d d8 mov%rcx,-0x28(%rbp) 444fe4: 4c 89 45 d0 mov%r8,-0x30(%rbp) 444fe8: 4c 89 4d c8 mov%r9,-0x38(%rbp) 444fec: 4c 8d 45 f0 lea-0x10(%rbp),%r8 444ff0: 48 8b 7d c8 mov-0x38(%rbp),%rdi 444ff4: 48 8b 4d d0 mov-0x30(%rbp),%rcx 444ff8: 8b 55 e0 mov-0x20(%rbp),%edx 444ffb: 8b 75 e4 mov-0x1c(%rbp),%esi 444ffe: 48 8b 45 e8 mov-0x18(%rbp),%rax 445002: 4d 89 c1 mov%r8,%r9 445005: 49 89 f8 mov%rdi,%r8 This is some seriously disgusting code... 444fe8: 4c 89 4d c8 mov%r9,-0x38(%rbp) 444ff0: 48 8b 7d c8 mov-0x38(%rbp),%rdi 445005: 49 89 f8 mov%rdi,%r8 gcc should be able to do better. Do you perhaps have --enable-debug in your mesa build? That disables -O2... If that is the case, might want to rerun your analysis without --enable-debug. -ilia 445008: 48 89 c7 mov%rax,%rdi 44500b: e8 78 fd ff ff callq 444d88 u_upload_alloc 445010: 89 45 fc mov%eax,-0x4(%rbp) 445013: 83 7d fc 00 cmpl $0x0,-0x4(%rbp) Pre change: 00444fce u_upload_data: 445017: 74 05je 44501e u_upload_data+0x50 445019: 8b 45 fc mov-0x4(%rbp),%eax 44501c: eb 1bjmp445039 u_upload_data+0x6b 44501e: 8b 55 e0 mov-0x20(%rbp),%edx 445021: 48 8b 45 f0 mov-0x10(%rbp),%rax 445025: 48 8b 4d d8 mov-0x28(%rbp),%rcx 445029: 48 89 ce mov%rcx,%rsi 44502c: 48 89 c7 mov%rax,%rdi 44502f: e8 2c 40 c0 ff callq 49060 memcpy@plt 445034: b8 00 00 00 00 mov$0x0,%eax 445039: c9 leaveq 44503a: c3 retq Post change: 00444fce u_upload_data: 445017: 75 16jne44502f u_upload_data+0x61 445019: 8b 55 e0 mov-0x20(%rbp),%edx 44501c: 48 8b 45 f0 mov-0x10(%rbp),%rax 445020: 48 8b 4d d8 mov-0x28(%rbp),%rcx 445024: 48 89 ce mov%rcx,%rsi 445027: 48 89 c7 mov%rax,%rdi 44502a: e8 31 40 c0 ff callq 49060 memcpy@plt 44502f: 8b 45 fc mov-0x4(%rbp),%eax 445032: c9 leaveq 445033: c3 retq With likely: 00444fce u_upload_data: 44501d: 48 85
[Mesa-dev] [Bug 75315] build failure with gcc -fsanitize=address
https://bugs.freedesktop.org/show_bug.cgi?id=75315 --- Comment #1 from Fabio Pedretti fabio@libero.it --- Still failing: https://launchpadlibrarian.net/176111981/buildlog_ubuntu-trusty-amd64.mesa_10.3~git1405221557.5dd927~gd~t_FAILEDTOBUILD.txt.gz -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] Revert i965/vec4: Change vec4_visitor::emit_lrp to use MAC for gen6
This reverts commit 2dfbbeca50b95ccdd714d9baa4411c779f6a20d9 with the comment about MAC and implicit accumulator removed. Why this code didn't work in all circumstances is unknown and without a working Ironlake simulator (which uses a different AUB format) we'll probably never know, short of a lot of experimentation, and spending a bunch of time to try to optimize a few instructions on Ironlake is not time well spent. Moreover, for mix(vec4, vec4, vec4) using the accumulator introduces a dependence between the otherwise independent per-component calculations. Not using the accumulator, even if it means an extra instruction per component might be preferable. We don't know, we don't have data, and we don't have the necessary register on Ironlake for shader_time to tell us. Cc: 10.2 mesa-sta...@lists.freedesktop.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77703 --- src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp index 7bad81c..54a40dd 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp @@ -1171,13 +1171,17 @@ vec4_visitor::emit_lrp(const dst_reg dst, /* Earlier generations don't support three source operations, so we * need to emit x*(1-a) + y*a. */ - dst_reg one_minus_a = dst_reg(this, glsl_type::vec4_type); - one_minus_a.writemask = dst.writemask; - + dst_reg y_times_a = dst_reg(this, glsl_type::vec4_type); + dst_reg one_minus_a = dst_reg(this, glsl_type::vec4_type); + dst_reg x_times_one_minus_a = dst_reg(this, glsl_type::vec4_type); + y_times_a.writemask = dst.writemask; + one_minus_a.writemask = dst.writemask; + x_times_one_minus_a.writemask = dst.writemask; + + emit(MUL(y_times_a, y, a)); emit(ADD(one_minus_a, negate(a), src_reg(1.0f))); - vec4_instruction *mul = emit(MUL(dst_null_f(), y, a)); - mul-writes_accumulator = true; - emit(MAC(dst, x, src_reg(one_minus_a))); + emit(MUL(x_times_one_minus_a, x, src_reg(one_minus_a))); + emit(ADD(dst, src_reg(x_times_one_minus_a), src_reg(y_times_a))); } } -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] Revert i965/fs: Change fs_visitor::emit_lrp to use MAC for gen6
This reverts commit a6860100b87415ab510d0d210cabfeeccebc9a0a.
Why this code didn't work in all circumstances is unknown and without a
working Ironlake simulator (which uses a different AUB format) we'll
probably never know, short of a lot of experimentation, and spending a
bunch of time to try to optimize a few instructions on Ironlake is not
time well spent.
Moreover, for mix(vec4, vec4, vec4) using the accumulator introduces a
dependence between the otherwise independent per-component calculations.
Not using the accumulator, even if it means an extra instruction per
component might be preferable. We don't know, we don't have data, and
we don't have the necessary register on Ironlake for shader_time to tell
us.
Cc: 10.2 mesa-sta...@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77707
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index dcc8441..ff3d0f7 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -224,15 +224,18 @@ fs_visitor::emit_lrp(const fs_reg dst, const fs_reg x,
const fs_reg y,
!y.is_valid_3src() ||
!a.is_valid_3src()) {
/* We can't use the LRP instruction. Emit x*(1-a) + y*a. */
+ fs_reg y_times_a = fs_reg(this, glsl_type::float_type);
fs_reg one_minus_a = fs_reg(this, glsl_type::float_type);
+ fs_reg x_times_one_minus_a = fs_reg(this, glsl_type::float_type);
+
+ emit(MUL(y_times_a, y, a));
fs_reg negative_a = a;
negative_a.negate = !a.negate;
-
emit(ADD(one_minus_a, negative_a, fs_reg(1.0f)));
- fs_inst *mul = emit(MUL(reg_null_f, y, a));
- mul-writes_accumulator = true;
- emit(MAC(dst, x, one_minus_a));
+ emit(MUL(x_times_one_minus_a, x, one_minus_a));
+
+ emit(ADD(dst, x_times_one_minus_a, y_times_a));
} else {
/* The LRP instruction actually does op1 * op0 + op2 * (1 - op0), so
* we need to reorder the operands.
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 79081] New: [regression] build failure - error: 'cpu_features_ecx' undeclared (first use in this function)
https://bugs.freedesktop.org/show_bug.cgi?id=79081 Priority: medium Bug ID: 79081 CC: matts...@gmail.com Assignee: mesa-dev@lists.freedesktop.org Summary: [regression] build failure - error: 'cpu_features_ecx' undeclared (first use in this function) Severity: critical Classification: Unclassified OS: Linux (All) Reporter: fabio@libero.it Hardware: x86 (IA32) Status: NEW Version: git Component: Mesa core Product: Mesa Building is broken on i386 after latest changes. Full log here: https://launchpadlibrarian.net/176124560/buildlog_ubuntu-trusty-i386.mesa_10.3~git1405221930.f935df~gd~t_FAILEDTOBUILD.txt.gz -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 79081] [regression] build failure - error: 'cpu_features_ecx' undeclared (first use in this function)
https://bugs.freedesktop.org/show_bug.cgi?id=79081 Matt Turner matts...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Matt Turner matts...@gmail.com --- Whew. That was embarrassing. Thanks for the quick report! -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 79081] [regression] build failure - error: 'cpu_features_ecx' undeclared (first use in this function)
https://bugs.freedesktop.org/show_bug.cgi?id=79081 --- Comment #2 from Matt Turner matts...@gmail.com --- http://cgit.freedesktop.org/mesa/mesa/commit/?id=a9bc85f3b21e8d1b2640933b3c9e0a8fe3b4b9c6 -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): mesa/x86: Support SSE 4.1 detection on x86-64.
- Original Message -
Module: Mesa
Branch: master
Commit: 8b9302f2b4b0536abb91cb73682ec13640fe9eaf
URL:
https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/mesa/mesa/commit/?id%3D8b9302f2b4b0536abb91cb73682ec13640fe9eafk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=AHdyjIRaIN8X%2FncnNP4l%2F2q0EVpdwrRXXlwYLuND8t0%3D%0As=ea1ec7f75f3ac94752601b896023c1f6f1d82af5cda565f7be3ea404c9b70866
Author: Matt Turner matts...@gmail.com
Date: Fri May 2 12:10:17 2014 -0700
mesa/x86: Support SSE 4.1 detection on x86-64.
Uses the cpuid.h header provided by gcc and clang. Other platforms are
encouraged to switch.
---
src/mesa/main/cpuinfo.c |2 +-
src/mesa/main/cpuinfo.h |2 +-
src/mesa/x86/common_x86.c | 11 +++
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/cpuinfo.c b/src/mesa/main/cpuinfo.c
index 8d482a6..73e295c 100644
--- a/src/mesa/main/cpuinfo.c
+++ b/src/mesa/main/cpuinfo.c
@@ -34,7 +34,7 @@
void
_mesa_get_cpu_features(void)
{
-#ifdef USE_X86_ASM
+#if defined USE_X86_ASM || (defined __x86_64__ !defined _MSC_VER)
_mesa_get_x86_features();
#endif
This broke several build types because it assumes that assembly is always used
on 64 bits except MSVC, which is not true. Windows builds are not using
assembly neither.
I think that `(defined __x86_64__ !defined _MSC_VER)` should be replaced
with `defined USE_X86_64_ASM` . After all that's why we have the USE_*_ASM
defines -- so that C code doesn't need to guess (and miserably) if/when
assembly is being used.
I'll draft a patch.
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] scons: Fix x86_64 build.
From: José Fonseca jfons...@vmware.com x86/common_x86.c is required also for x86_64 builds. --- src/mesa/SConscript | 1 + 1 file changed, 1 insertion(+) diff --git a/src/mesa/SConscript b/src/mesa/SConscript index cd959be..f565786 100644 --- a/src/mesa/SConscript +++ b/src/mesa/SConscript @@ -392,6 +392,7 @@ if (env['gcc'] or env['clang']) and \ 'USE_X86_64_ASM', ]) mesa_sources += [ +'x86/common_x86.c', 'x86-64/x86-64.c', 'x86-64/xform4.S', ] -- 2.0.0.rc2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] mesa: Rely on USE_X86_64_ASM.
From: José Fonseca jfons...@vmware.com
This fixes MinGW x64 builds. We don't use assembly on any of the
Windows builds, to avoid divergence between MSVC and MinGW when testing.
---
src/mesa/main/cpuinfo.c | 2 +-
src/mesa/main/cpuinfo.h | 2 +-
src/mesa/x86/common_x86.c | 6 +++---
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/cpuinfo.c b/src/mesa/main/cpuinfo.c
index 73e295c..0755d6b 100644
--- a/src/mesa/main/cpuinfo.c
+++ b/src/mesa/main/cpuinfo.c
@@ -34,7 +34,7 @@
void
_mesa_get_cpu_features(void)
{
-#if defined USE_X86_ASM || (defined __x86_64__ !defined _MSC_VER)
+#if defined USE_X86_ASM || defined USE_X86_64_ASM
_mesa_get_x86_features();
#endif
}
diff --git a/src/mesa/main/cpuinfo.h b/src/mesa/main/cpuinfo.h
index fcd611e..57925e8 100644
--- a/src/mesa/main/cpuinfo.h
+++ b/src/mesa/main/cpuinfo.h
@@ -27,7 +27,7 @@
#define CPUINFO_H
-#if defined USE_X86_ASM || (defined __x86_64__ !defined _MSC_VER)
+#if defined USE_X86_ASM || defined USE_X86_64_ASM
#include x86/common_x86_asm.h
#endif
diff --git a/src/mesa/x86/common_x86.c b/src/mesa/x86/common_x86.c
index a55c48e..9c12339 100644
--- a/src/mesa/x86/common_x86.c
+++ b/src/mesa/x86/common_x86.c
@@ -47,7 +47,7 @@
#include sys/sysctl.h
#include machine/cpu.h
#endif
-#if defined(__x86_64__) !defined(_MSC_VER)
+#if defined(USE_X86_64_ASM)
#include cpuid.h
#endif
@@ -336,7 +336,7 @@ _mesa_get_x86_features(void)
}
#endif
-#elif defined(__x86_64__) !defined(_MSC_VER)
+#elif defined(USE_X86_64_ASM)
unsigned int uninitialized_var(eax), uninitialized_var(ebx),
uninitialized_var(ecx), uninitialized_var(edx);
@@ -347,7 +347,7 @@ _mesa_get_x86_features(void)
if (ecx bit_SSE4_1)
_mesa_x86_cpu_features |= X86_FEATURE_SSE4_1;
-#endif /* USE_X86_ASM */
+#endif /* USE_X86_64_ASM */
(void) detection_debug;
}
--
2.0.0.rc2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] mesa: Rely on USE_X86_64_ASM.
On Thu, May 22, 2014 at 12:46 PM, jfons...@vmware.com wrote: From: José Fonseca jfons...@vmware.com This fixes MinGW x64 builds. We don't use assembly on any of the Windows builds, to avoid divergence between MSVC and MinGW when testing. --- If these solve your problems, I'm happy. Both are Reviewed-by: Matt Turner matts...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): mesa/x86: Support SSE 4.1 detection on x86-64.
On Thu, May 22, 2014 at 12:30 PM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
Module: Mesa
Branch: master
Commit: 8b9302f2b4b0536abb91cb73682ec13640fe9eaf
URL:
https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/mesa/mesa/commit/?id%3D8b9302f2b4b0536abb91cb73682ec13640fe9eafk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=AHdyjIRaIN8X%2FncnNP4l%2F2q0EVpdwrRXXlwYLuND8t0%3D%0As=ea1ec7f75f3ac94752601b896023c1f6f1d82af5cda565f7be3ea404c9b70866
Author: Matt Turner matts...@gmail.com
Date: Fri May 2 12:10:17 2014 -0700
mesa/x86: Support SSE 4.1 detection on x86-64.
Uses the cpuid.h header provided by gcc and clang. Other platforms are
encouraged to switch.
---
src/mesa/main/cpuinfo.c |2 +-
src/mesa/main/cpuinfo.h |2 +-
src/mesa/x86/common_x86.c | 11 +++
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/cpuinfo.c b/src/mesa/main/cpuinfo.c
index 8d482a6..73e295c 100644
--- a/src/mesa/main/cpuinfo.c
+++ b/src/mesa/main/cpuinfo.c
@@ -34,7 +34,7 @@
void
_mesa_get_cpu_features(void)
{
-#ifdef USE_X86_ASM
+#if defined USE_X86_ASM || (defined __x86_64__ !defined _MSC_VER)
_mesa_get_x86_features();
#endif
This broke several build types because it assumes that assembly is always
used on 64 bits except MSVC, which is not true. Windows builds are not using
assembly neither.
I think that `(defined __x86_64__ !defined _MSC_VER)` should be replaced
with `defined USE_X86_64_ASM` . After all that's why we have the USE_*_ASM
defines -- so that C code doesn't need to guess (and miserably) if/when
assembly is being used.
I'll draft a patch.
Jose
Interesting. I was worried about breaking MSVC, since I don't think it
has a compatible cpuid.h header. We might consider renaming the
USE_*_ASM macros. The code I was enabling here is written using _mm_*
intrinsics, available on all x86 compilers as far as I'm aware, and
not assembly. The CPU feature detection code doesn't need any assembly
in Mesa either.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] Revert i965/vec4: Change vec4_visitor::emit_lrp to use MAC for gen6
On 05/22/2014 09:55 AM, Matt Turner wrote: This reverts commit 2dfbbeca50b95ccdd714d9baa4411c779f6a20d9 with the comment about MAC and implicit accumulator removed. Why this code didn't work in all circumstances is unknown and without a working Ironlake simulator (which uses a different AUB format) we'll probably never know, short of a lot of experimentation, and spending a bunch of time to try to optimize a few instructions on Ironlake is not time well spent. Moreover, for mix(vec4, vec4, vec4) using the accumulator introduces a dependence between the otherwise independent per-component calculations. Not using the accumulator, even if it means an extra instruction per component might be preferable. We don't know, we don't have data, and we don't have the necessary register on Ironlake for shader_time to tell us. Cc: 10.2 mesa-sta...@lists.freedesktop.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77703 --- src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp index 7bad81c..54a40dd 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp @@ -1171,13 +1171,17 @@ vec4_visitor::emit_lrp(const dst_reg dst, /* Earlier generations don't support three source operations, so we * need to emit x*(1-a) + y*a. */ - dst_reg one_minus_a = dst_reg(this, glsl_type::vec4_type); - one_minus_a.writemask = dst.writemask; - + dst_reg y_times_a = dst_reg(this, glsl_type::vec4_type); + dst_reg one_minus_a = dst_reg(this, glsl_type::vec4_type); + dst_reg x_times_one_minus_a = dst_reg(this, glsl_type::vec4_type); + y_times_a.writemask = dst.writemask; + one_minus_a.writemask = dst.writemask; + x_times_one_minus_a.writemask = dst.writemask; + + emit(MUL(y_times_a, y, a)); emit(ADD(one_minus_a, negate(a), src_reg(1.0f))); - vec4_instruction *mul = emit(MUL(dst_null_f(), y, a)); - mul-writes_accumulator = true; - emit(MAC(dst, x, src_reg(one_minus_a))); + emit(MUL(x_times_one_minus_a, x, src_reg(one_minus_a))); + emit(ADD(dst, src_reg(x_times_one_minus_a), src_reg(y_times_a))); } } Both reverts are: Acked-by: Kenneth Graunke kenn...@whitecape.org signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): mesa/x86: Support SSE 4.1 detection on x86-64.
- Original Message -
On Thu, May 22, 2014 at 12:30 PM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
Module: Mesa
Branch: master
Commit: 8b9302f2b4b0536abb91cb73682ec13640fe9eaf
URL:
https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/mesa/mesa/commit/?id%3D8b9302f2b4b0536abb91cb73682ec13640fe9eafk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=AHdyjIRaIN8X%2FncnNP4l%2F2q0EVpdwrRXXlwYLuND8t0%3D%0As=ea1ec7f75f3ac94752601b896023c1f6f1d82af5cda565f7be3ea404c9b70866
Author: Matt Turner matts...@gmail.com
Date: Fri May 2 12:10:17 2014 -0700
mesa/x86: Support SSE 4.1 detection on x86-64.
Uses the cpuid.h header provided by gcc and clang. Other platforms are
encouraged to switch.
---
src/mesa/main/cpuinfo.c |2 +-
src/mesa/main/cpuinfo.h |2 +-
src/mesa/x86/common_x86.c | 11 +++
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/cpuinfo.c b/src/mesa/main/cpuinfo.c
index 8d482a6..73e295c 100644
--- a/src/mesa/main/cpuinfo.c
+++ b/src/mesa/main/cpuinfo.c
@@ -34,7 +34,7 @@
void
_mesa_get_cpu_features(void)
{
-#ifdef USE_X86_ASM
+#if defined USE_X86_ASM || (defined __x86_64__ !defined _MSC_VER)
_mesa_get_x86_features();
#endif
This broke several build types because it assumes that assembly is always
used on 64 bits except MSVC, which is not true. Windows builds are not
using assembly neither.
I think that `(defined __x86_64__ !defined _MSC_VER)` should be replaced
with `defined USE_X86_64_ASM` . After all that's why we have the USE_*_ASM
defines -- so that C code doesn't need to guess (and miserably) if/when
assembly is being used.
I'll draft a patch.
Jose
Interesting. I was worried about breaking MSVC, since I don't think it
has a compatible cpuid.h header. We might consider renaming the
USE_*_ASM macros. The code I was enabling here is written using _mm_*
intrinsics, available on all x86 compilers as far as I'm aware, and
not assembly.
The CPU feature detection code doesn't need any assembly
in Mesa either
Right. We have *.s and intrisics. *.s is gcc only. But x86 instrinsics are
more portable. And we might indeed want to make USE_*_ASM more fine grained,
but ATM it is enough.
jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] MaxAnisotropy with GL_NEAREST on i965
Greetings,
I ran into a problem with how Mesa on i965 handles MaxAnisotropy.
The app I'm looking at sets sampler state min and mag filters to GL_NEAREST,
but also sets GL_TEXTURE_MAX_ANISOTROPY_EXT, like so:
glSamplerParameteri(pointSampler, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glSamplerParameteri(pointSampler, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glSamplerParameteri(pointSampler, GL_TEXTURE_MAX_ANISOTROPY_EXT, 8);
On Nvidia closed source and Intel closed source drivers, MaxAnisotropy is
ignored and unfiltered texture results are returned. In this case, solid
red.
Using Haswell with Mesa, MaxAnisotropy trumps GL_NEAREST, and the texels
are filtered, returning almost greyscale values. See
gen7_update_sampler_state().
According to the extension, both behaviors are allowed:
http://www.opengl.org/registry/specs/EXT/texture_filter_anisotropic.txt
Implementations are free to use the specified minification and
magnification filter to select a particular anisotropic texture
filtering scheme. For example, a NEAREST filter with a maximum
degree of anisotropy of two could be treated as a 2-tap filter that
accounts for the direction of anisotropy. Implementations are also
permitted to ignore the minification or magnification filter and
implement the highest quality of anisotropic filtering possible.
So no one is at fault here, it's just different. What's the policy for
ambiguities like this? Should i965 match other vendors? Or emit a warning
that requested filter mode is being overridden?
Below are modifications to a piglit test that show the problem. I couldn't
find any existing tests for EXT_texture_filter_anisotropic. The changes
fill a single LOD texture with interleaved colors, then expects a single
unfiltered red color back, but i965 returns greenish brown.
Thanks,
-Cody
diff --git
a/tests/spec/arb_separate_shader_objects/rendezvous_by_location.c
b/tests/spec/arb_separate_shader_objects/rendezvous_by_location.c
index 4193ea5..7e83890 100644
--- a/tests/spec/arb_separate_shader_objects/rendezvous_by_location.c
+++ b/tests/spec/arb_separate_shader_objects/rendezvous_by_location.c
@@ -95,6 +95,7 @@ static const char *fs_code_same_location_order_template =
#version %d\n
#extension GL_ARB_separate_shader_objects: require\n
#extension GL_ARB_explicit_attrib_location: enable\n
+ #extension GL_ARB_shading_language_420pack: require\n
\n
#if __VERSION__ = 130\n
layout(location = 0) out vec4 out_color;\n
@@ -104,13 +105,53 @@ static const char
*fs_code_same_location_order_template =
\n
layout(location = 2) in vec3 b; /* should get vec3(0, 0, 1) */\n
layout(location = 3) in vec3 a; /* should get vec3(1, 0, 0) */\n
+ layout(binding = 10) uniform sampler2D interleavedTexture;\n
\n
void main()\n
{\n
- out_color = vec4(cross(b, a), 1);\n
+ out_color = texture2D(interleavedTexture, vec2(0.0, 0.0));\n
}\n
;
+/**
+ * Create a an image with 3 interleaved colors.
+ */
+static GLubyte *
+create_interleaved_image(GLint w, GLint h, const GLubyte red[4], const
GLubyte green[4], const GLubyte blue[4])
+{
+ GLubyte *buf = (GLubyte *) malloc(w * h * 4);
+ int i;
+ for (i = 0; i w * h; i++) {
+
+ switch(i % 3) {
+ case 0:
+ buf[i*4+0] = red[0];
+ buf[i*4+1] = red[1];
+ buf[i*4+2] = red[2];
+ buf[i*4+3] = red[3];
+ break;
+
+ case 1:
+ buf[i*4+0] = green[0];
+ buf[i*4+1] = green[1];
+ buf[i*4+2] = green[2];
+ buf[i*4+3] = green[3];
+ break;
+
+ case 2:
+ buf[i*4+0] = blue[0];
+ buf[i*4+1] = blue[1];
+ buf[i*4+2] = blue[2];
+ buf[i*4+3] = blue[3];
+ break;
+
+ default:
+ break;
+ }
+ }
+ return buf;
+}
+
enum piglit_result
piglit_display(void)
{
@@ -119,6 +160,73 @@ piglit_display(void)
};
bool pass;
+ static GLubyte redColors[][4] = {
+ {255, 0, 0, 255},
+ {255, 0, 0, 255},
+ {255, 0, 0, 255},
+ {255, 0, 0, 255},
+ {255, 0, 0, 255},
+ {255, 0, 0, 255},
+ {255, 0, 0, 255},
+ {255, 0, 0, 255},
+ {255, 0, 0, 255},
+ {255, 0, 0, 255}
+ };
+
+ static GLubyte greenColors[][4] = {
+ { 0, 255, 0, 255},
+ { 0, 255, 0, 255},
+ { 0, 255, 0, 255},
+ { 0, 255, 0, 255},
+ { 0, 255, 0,
Re: [Mesa-dev] [PATCH 19/23] i965/fs: Use next_insn_offset rather than nr_insn.
On 05/19/2014 11:55 AM, Matt Turner wrote:
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 4 ++--
src/mesa/drivers/dri/i965/gen8_fs_generator.cpp | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index 872b5a4..914fb29 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -1843,12 +1843,12 @@ fs_generator::generate_assembly(exec_list
*simd8_instructions,
if (simd16_instructions) {
/* align to 64 byte boundary. */
- while ((p-nr_insn * sizeof(struct brw_instruction)) % 64) {
+ while (p-next_insn_offset % 64) {
brw_NOP(p);
}
So, I wondered how this worked (before and after your change). In
theory, we could have an odd number of compacted instructions, giving us
a next_insn_offset of (64*n + 2). Emitting uncompacted NOPs adds 4
bytes each time, which would never get us to a multiple of 64.
Apparently, this doesn't happen because sendc cannot be compacted and
must be aligned on a 128-bit/4-byte boundary. So, it works.
Someday we should probably just do:
p-next_insn_offset = ALIGN(p-next_insn_offset, 64);
and memset to 0 between the two programs.
In the meantime, this seems better than the existing code.
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
/* Save off the start of this SIMD16 program */
- prog_data-prog_offset_16 = p-nr_insn * sizeof(struct
brw_instruction);
+ prog_data-prog_offset_16 = p-next_insn_offset;
brw_set_compression_control(p, BRW_COMPRESSION_COMPRESSED);
diff --git a/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
b/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
index 9011bff..272f668 100644
--- a/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
@@ -1330,11 +1330,11 @@ gen8_fs_generator::generate_assembly(exec_list
*simd8_instructions,
if (simd16_instructions) {
/* Align to a 64-byte boundary. */
- while ((nr_inst * sizeof(gen8_instruction)) % 64)
+ while (next_inst_offset % 64)
NOP();
/* Save off the start of this SIMD16 program */
- prog_data-prog_offset_16 = nr_inst * sizeof(gen8_instruction);
+ prog_data-prog_offset_16 = next_inst_offset;
struct annotation *annotation;
int num_annotations;
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 17/23] i965: Switch types D-UD when possible to allow compaction.
On Wed, May 21, 2014 at 4:08 PM, Eric Anholt e...@anholt.net wrote:
Matt Turner matts...@gmail.com writes:
Number of compacted instructions: 827404 - 833045 (0.68%)
---
src/mesa/drivers/dri/i965/brw_eu_emit.c | 20
1 file changed, 20 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index 1810233..ab00d7c 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
@@ -295,6 +295,16 @@ validate_reg(struct brw_instruction *insn, struct
brw_reg reg)
/* 10. Check destination issues. */
}
+static bool
+is_compactable_immediate(unsigned imm)
+{
+ /* We get the low 12 bits as-is. */
+ imm = ~0xfff;
+
+ /* We get one bit replicated through the top 20 bits. */
+ return imm == 0 || imm == 0xf000;
+}
+
void
brw_set_src0(struct brw_compile *p, struct brw_instruction *insn,
struct brw_reg reg)
@@ -373,6 +383,16 @@ brw_set_src0(struct brw_compile *p, struct
brw_instruction *insn,
insn-bits1.da1.src0_reg_type == BRW_HW_REG_TYPE_F) {
insn-bits1.da1.src0_reg_type = BRW_HW_REG_IMM_TYPE_VF;
}
+
+ /* There are no mappings for dst:d | i:d, so if the immediate is
suitable
+ * set the types to :UD so the instruction can be compacted.
+ */
+ if (is_compactable_immediate(insn-bits3.ud)
+ insn-bits1.da1.src0_reg_type == BRW_HW_REG_TYPE_D
+ insn-bits1.da1.dest_reg_type == BRW_HW_REG_TYPE_D) {
+ insn-bits1.da1.src0_reg_type = BRW_HW_REG_TYPE_UD;
+ insn-bits1.da1.dest_reg_type = BRW_HW_REG_TYPE_UD;
+ }
Do conditional modifier flags work the same for the same data with D
versus UD destinations? Just trying to come up with cases where
changing the type would matter.
I think it'd be different if we did something like
mov.le.f0 dst:D, -1D
and converted it to
mov.le.f0 dst:UD, 0xUD
you'd get the same bits in dst, but a different value in f0.
I can't imagine we'll ever emit a mov/cmod/immediate-source, but that
also means we'd never lose anything by disabling it this if there's
cmod.
I'll change the conditional to include
insn-header.destreg__conditionalmod == 0.
With that fixed, it gets your R-b?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] loader: add optional /sys filesystem method for PCI identification.
On 22/05/14 04:58, Gary Wong wrote:
On Wed, May 21, 2014 at 07:46:52PM +0100, Emil Velikov wrote:
On 21/05/14 02:40, Gary Wong wrote:
Introduce a simple PCI identification method of looking up the answer
the /sys filesystem (available on Linux). Attempted after libudev, but
before DRM.
Disabled by default (available only when the --enable-sysfs configure
option is specified).
Gary does uevent provide the full device path on your system ?
No (see below).
Can you please keep the code style similar to the rest of the file
- no space around [] and ()
- use sizeof(bla)
- (pedantic) snprintf can fail/truncate.
- empty lines with whitespace
Thanks... I tried to match, but wasn't aware of a couple of those points
and some of the others fell through the cracks.
I'm not sure how to best handle snprintf here... the only conversions
used are %d, and they cannot possibly overflow the (constant size) buffers
unless both UINT_MAX and dev_t are very large (on the order of 10^16). But
I don't know a good way to express that. How do you feel about: just plain
sprintf() with comments about conditions under which it's always safe;
snprintf() with dynamic buffer allocation; #if/#error tests on UINT_MAX;
or something else?
The buffer size expressed in hex kind of threw me over a bit. AFAICS things
should be safe as is. Unless things are fundamentally broken.
-PKG_CHECK_MODULES([LIBUDEV], [libudev = $LIBUDEV_REQUIRED],
- have_libudev=yes, have_libudev=no)
+AC_ARG_ENABLE([libudev],
+[AS_HELP_STRING([--disable-libudev],
+[disable libudev PCI identification @:@default=enabled on
supported platforms@:@])],
Not strictly correct. I would just go with auto
+[attempt_libudev=$enableval],
+[attempt_libudev=yes]
[enable_libudev=$enableval],
[enable_libudev=auto]
The above is more consistent with the mayhem that our current configure.ac :)
On further thought, I'll revert that section of the commit. The
--disable-libudev option is silly, because the whole point of this patch
is to carry on working at runtime even if libudev fails (therefore having
it in cannot hurt, so why have an option not to?).
Fair enough. The less options the better.
+static char *
+sysfs_get_device_name_for_fd(int fd)
+{
On my linux system this approach returns dri/card0 only. Whereas it should
produce /dev/dri/card0.
Oops, well spotted! My system does the same. I assumed libudev would
also have returned the partial path so misunderstood the intended return.
Oddly enough Mesa worked perfectly well for me with the short name... I
can exercise it on only one hardware type, and perhaps in my case it turns
out not to be critical. Thanks very much for catching that one!
I'm guessing that you've never actually hit this code. IIRC there are two
use-cases - in the dri2 and gallium backends of the egl driver. If you're
really into it you can attach a debugger and check.
-Emil
Thank you for the detailed comments... I'll send revised patches in a minute.
Gary.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] loader: add optional /sys filesystem method for PCI identification.
On 22/05/14 05:01, Gary Wong wrote:
Introduce a simple PCI identification method of looking up the answer
the /sys filesystem (available on Linux). Attempted after libudev, but
before DRM.
Disabled by default (available only when the --enable-sysfs configure
option is specified).
Imo the sysfs_get_device_name_for_fd() function looks rather messy, but
luckily most people will never hit it so :)
With that said, this patch is
Acked-by: Emil Velikov emil.l.veli...@gmail.com
I will give it a week or so for other people to chip in before pushing these
to master.
Thanks for your contribution.
Emil
P.S. If you use --in-reply-to, --chain-reply-to you'll have greater chances of
patches not getting lost :)
Signed-off-by: Gary Wong g...@gnu.org
---
configure.ac| 36 +++--
src/loader/loader.c | 112
2 files changed, 137 insertions(+), 11 deletions(-)
diff --git a/configure.ac b/configure.ac
index 4e4d761..95f0e16 100644
--- a/configure.ac
+++ b/configure.ac
@@ -818,14 +818,21 @@ fi
case $host_os in
linux*)
-need_libudev=yes ;;
+need_pci_id=yes ;;
*)
-need_libudev=no ;;
+need_pci_id=no ;;
esac
PKG_CHECK_MODULES([LIBUDEV], [libudev = $LIBUDEV_REQUIRED],
have_libudev=yes, have_libudev=no)
+AC_ARG_ENABLE([sysfs],
+[AS_HELP_STRING([--enable-sysfs],
+[enable /sys PCI identification @:@default=disabled@:@])],
+[have_sysfs=$enableval],
+[have_sysfs=no]
+)
+
if test x$enable_dri = xyes; then
if test $enable_static = yes; then
AC_MSG_ERROR([Cannot use static libraries for DRI drivers])
@@ -910,8 +917,15 @@ xyesno)
;;
esac
+have_pci_id=no
if test $have_libudev = yes; then
DEFINES=$DEFINES -DHAVE_LIBUDEV
+have_pci_id=yes
+fi
+
+if test $have_sysfs = yes; then
+DEFINES=$DEFINES -DHAVE_SYSFS
+have_pci_id=yes
fi
# This is outside the case (above) so that it is invoked even for non-GLX
@@ -1013,8 +1027,8 @@ if test x$enable_dri = xyes; then
DEFINES=$DEFINES -DHAVE_DRI3
fi
-if test x$have_libudev != xyes; then
-AC_MSG_ERROR([libudev-dev required for building DRI])
+if test x$have_pci_id != xyes; then
+AC_MSG_ERROR([libudev-dev or sysfs required for building DRI])
fi
case $host_cpu in
@@ -1183,8 +1197,8 @@ if test x$enable_gbm = xauto; then
esac
fi
if test x$enable_gbm = xyes; then
-if test x$need_libudev$have_libudev = xyesno; then
-AC_MSG_ERROR([gbm requires udev = $LIBUDEV_REQUIRED])
+if test x$need_pci_id$have_pci_id = xyesno; then
+AC_MSG_ERROR([gbm requires udev = $LIBUDEV_REQUIRED or sysfs])
fi
if test x$enable_dri = xyes; then
@@ -1202,7 +1216,7 @@ if test x$enable_gbm = xyes; then
fi
fi
AM_CONDITIONAL(HAVE_GBM, test x$enable_gbm = xyes)
-if test x$need_libudev = xyes; then
+if test x$need_pci_id$have_libudev = xyesyes; then
GBM_PC_REQ_PRIV=libudev = $LIBUDEV_REQUIRED
else
GBM_PC_REQ_PRIV=
@@ -1491,9 +1505,9 @@ for plat in $egl_platforms; do
;;
esac
-case $plat$need_libudev$have_libudev in
+case $plat$need_pci_id$have_pci_id in
waylandyesno|drmyesno)
-AC_MSG_ERROR([cannot build $plat platform without udev
= $LIBUDEV_REQUIRED]) ;;
+AC_MSG_ERROR([cannot build $plat platform without udev
= $LIBUDEV_REQUIRED or sysfs]) ;;
esac
done
@@ -1766,8 +1780,8 @@ gallium_require_llvm() {
gallium_require_drm_loader() {
if test x$enable_gallium_loader = xyes; then
-if test x$need_libudev$have_libudev = xyesno; then
-AC_MSG_ERROR([Gallium drm loader requires libudev =
$LIBUDEV_REQUIRED])
+if test x$need_pci_id$have_pci_id = xyesno; then
+AC_MSG_ERROR([Gallium drm loader requires libudev =
$LIBUDEV_REQUIRED or sysfs])
fi
if test x$have_libdrm != xyes; then
AC_MSG_ERROR([Gallium drm loader requires libdrm =
$LIBDRM_REQUIRED])
diff --git a/src/loader/loader.c b/src/loader/loader.c
index 52be706..0f26265 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -71,6 +71,10 @@
#include assert.h
#include dlfcn.h
#endif
+#ifdef HAVE_SYSFS
+#include sys/stat.h
+#include sys/types.h
+#endif
#include loader.h
#ifndef __NOT_HAVE_DRM_H
@@ -212,6 +216,66 @@ out:
}
#endif
+#if defined(HAVE_SYSFS)
+static int
+dev_node_from_fd(int fd, unsigned int *maj, unsigned int *min)
+{
+ struct stat buf;
+
+ if (fstat(fd, buf) 0) {
+ log_(_LOADER_WARNING, MESA-LOADER: failed to stat fd %d\n, fd);
+ return -1;
+ }
+
+ if (!S_ISCHR(buf.st_mode)) {
+ log_(_LOADER_WARNING, MESA-LOADER: fd %d not a character device\n,
fd);
+ return -1;
+ }
+
+ *maj =
Re: [Mesa-dev] [PATCH 2/2] loader: add optional /sys filesystem method for PCI identification.
On Fri, May 23, 2014 at 12:31:54AM +0100, Emil Velikov wrote: I will give it a week or so for other people to chip in before pushing these to master. Actually, I have permission to push, so I can do that next week to save you the effort of remembering. Thanks for your contribution. Thank you very much for your corrections! P.S. If you use --in-reply-to, --chain-reply-to you'll have greater chances of patches not getting lost :) Ah, thanks, that's useful to know. Cheers, Gary. -- Gary Wong g...@gnu.org http://www.cs.utah.edu/~gtw/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 79095] New: x86/common_x86.c:348:14: error: use of undeclared identifier 'bit_SSE4_1'
https://bugs.freedesktop.org/show_bug.cgi?id=79095 Priority: medium Bug ID: 79095 Keywords: regression CC: matts...@gmail.com Assignee: mesa-dev@lists.freedesktop.org Summary: x86/common_x86.c:348:14: error: use of undeclared identifier 'bit_SSE4_1' Severity: blocker Classification: Unclassified OS: Linux (All) Reporter: v...@freedesktop.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Mesa core Product: Mesa mesa: f50361cce79beb78119d835b7a52c0c790d74077 (master 10.3.0-devel) clang build error CC common_x86.lo x86/common_x86.c:348:14: error: use of undeclared identifier 'bit_SSE4_1' if (ecx bit_SSE4_1) ^ commit a2fb71e23bced3f3585e91726590efe6034a10ed Author: Matt Atwood matthew.s.atw...@intel.com Date: Fri May 2 09:44:44 2014 -0700 mesa/x86: add SSE4.1 runtime detection. Add a bit to _mesa_x86_features for SSE 4.1, along with macros to query. Reviewed-by: Matt Turner matts...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] glxinfo: move reusable, non-GLX code into glinfo_common.[ch]
So that we can share some of the code with wglinfo.
---
src/xdemos/CMakeLists.txt |4 +-
src/xdemos/Makefile.am |4 +
src/xdemos/glinfo_common.c | 649
src/xdemos/glinfo_common.h | 89 ++
src/xdemos/glxinfo.c | 647 +--
5 files changed, 759 insertions(+), 634 deletions(-)
create mode 100644 src/xdemos/glinfo_common.c
create mode 100644 src/xdemos/glinfo_common.h
diff --git a/src/xdemos/CMakeLists.txt b/src/xdemos/CMakeLists.txt
index ee8b12d..97329fe 100644
--- a/src/xdemos/CMakeLists.txt
+++ b/src/xdemos/CMakeLists.txt
@@ -34,7 +34,6 @@ set (targets
glxgears_fbconfig
glxgears_pixmap
glxheads
- glxinfo
glxpbdemo
glxpixmap
glxsnoop
@@ -73,5 +72,6 @@ target_link_libraries (${subdir}_sharedtex_mt pthread)
add_executable (corender corender.c ipc.c)
add_executable (xrotfontdemo xrotfontdemo.c xuserotfont.c)
+add_executable (glxinfo glxinfo.c glinfo_common.c)
-install (TARGETS corender xrotfontdemo DESTINATION demos)
+install (TARGETS glxinfo corender xrotfontdemo DESTINATION demos)
diff --git a/src/xdemos/Makefile.am b/src/xdemos/Makefile.am
index 373e7c2..0bdf13d 100644
--- a/src/xdemos/Makefile.am
+++ b/src/xdemos/Makefile.am
@@ -77,6 +77,10 @@ xrotfontdemo_SOURCES = \
xuserotfont.c \
xuserotfont.h
+glxinfo_SOURCES = \
+ glxinfo.c \
+ glinfo_common.c
+
glthreads_LDADD = -lpthread
glxgears_fbconfig_LDADD = libpbutil.la
pbdemo_LDADD = libpbutil.la
diff --git a/src/xdemos/glinfo_common.c b/src/xdemos/glinfo_common.c
new file mode 100644
index 000..e6517d7
--- /dev/null
+++ b/src/xdemos/glinfo_common.c
@@ -0,0 +1,649 @@
+/*
+ * Copyright (C) 1999-2014 Brian Paul All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included
+ * in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * BRIAN PAUL BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
+ * AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include assert.h
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include glinfo_common.h
+
+
+/**
+ * Return the GL enum name for a numeric value.
+ * We really only care about the compressed texture formats for now.
+ */
+static const char *
+enum_name(GLenum val)
+{
+ static const struct {
+ const char *name;
+ GLenum val;
+ } enums [] = {
+ { GL_COMPRESSED_ALPHA, 0x84E9 },
+ { GL_COMPRESSED_LUMINANCE, 0x84EA },
+ { GL_COMPRESSED_LUMINANCE_ALPHA, 0x84EB },
+ { GL_COMPRESSED_INTENSITY, 0x84EC },
+ { GL_COMPRESSED_RGB, 0x84ED },
+ { GL_COMPRESSED_RGBA, 0x84EE },
+ { GL_COMPRESSED_TEXTURE_FORMATS, 0x86A3 },
+ { GL_COMPRESSED_RGB, 0x84ED },
+ { GL_COMPRESSED_RGBA, 0x84EE },
+ { GL_COMPRESSED_TEXTURE_FORMATS, 0x86A3 },
+ { GL_COMPRESSED_ALPHA, 0x84E9 },
+ { GL_COMPRESSED_LUMINANCE, 0x84EA },
+ { GL_COMPRESSED_LUMINANCE_ALPHA, 0x84EB },
+ { GL_COMPRESSED_INTENSITY, 0x84EC },
+ { GL_COMPRESSED_SRGB, 0x8C48 },
+ { GL_COMPRESSED_SRGB_ALPHA, 0x8C49 },
+ { GL_COMPRESSED_SLUMINANCE, 0x8C4A },
+ { GL_COMPRESSED_SLUMINANCE_ALPHA, 0x8C4B },
+ { GL_COMPRESSED_RED, 0x8225 },
+ { GL_COMPRESSED_RG, 0x8226 },
+ { GL_COMPRESSED_RED_RGTC1, 0x8DBB },
+ { GL_COMPRESSED_SIGNED_RED_RGTC1, 0x8DBC },
+ { GL_COMPRESSED_RG_RGTC2, 0x8DBD },
+ { GL_COMPRESSED_SIGNED_RG_RGTC2, 0x8DBE },
+ { GL_COMPRESSED_RGB8_ETC2, 0x9274 },
+ { GL_COMPRESSED_SRGB8_ETC2, 0x9275 },
+ { GL_COMPRESSED_RGB8_PUNCHTHROUGH_ALPHA1_ETC2, 0x9276 },
+ { GL_COMPRESSED_SRGB8_PUNCHTHROUGH_ALPHA1_ETC2, 0x9277 },
+ { GL_COMPRESSED_RGBA8_ETC2_EAC, 0x9278 },
+ { GL_COMPRESSED_SRGB8_ALPHA8_ETC2_EAC, 0x9279 },
+ { GL_COMPRESSED_R11_EAC, 0x9270 },
+ { GL_COMPRESSED_SIGNED_R11_EAC, 0x9271 },
+ { GL_COMPRESSED_RG11_EAC, 0x9272 },
+ { GL_COMPRESSED_SIGNED_RG11_EAC, 0x9273 },
+ { GL_COMPRESSED_ALPHA_ARB, 0x84E9 },
+ { GL_COMPRESSED_LUMINANCE_ARB, 0x84EA },
+ { GL_COMPRESSED_LUMINANCE_ALPHA_ARB, 0x84EB },
+ {
[Mesa-dev] [PATCH 2/2] wglinfo: use common code from glinfo_common.c
---
src/wgl/CMakeLists.txt |3 +-
src/wgl/wglinfo.c | 532 ++--
2 files changed, 18 insertions(+), 517 deletions(-)
diff --git a/src/wgl/CMakeLists.txt b/src/wgl/CMakeLists.txt
index a32a664..d45cbf3 100644
--- a/src/wgl/CMakeLists.txt
+++ b/src/wgl/CMakeLists.txt
@@ -1,6 +1,7 @@
include_directories (
${OPENGL_INCLUDE_PATH}
${GLEW_INCLUDE_DIR}
+ ../xdemos
)
link_libraries (
@@ -12,7 +13,7 @@ add_executable (wglthreads wglthreads.c)
add_executable (wgl_sharedtex_mt sharedtex_mt.c)
set_target_properties (wgl_sharedtex_mt PROPERTIES OUTPUT_NAME sharedtex_mt)
-add_executable (wglinfo wglinfo.c)
+add_executable (wglinfo wglinfo.c ../xdemos/glinfo_common.c)
add_executable (wglcontext wglcontext.c)
add_executable (wincopy WIN32 wincopy.c wglutil.c)
diff --git a/src/wgl/wglinfo.c b/src/wgl/wglinfo.c
index b54c3b6..2b2c921 100644
--- a/src/wgl/wglinfo.c
+++ b/src/wgl/wglinfo.c
@@ -39,6 +39,7 @@
#include stdio.h
#include string.h
#include stdlib.h
+#include glinfo_common.h
typedef enum
@@ -49,520 +50,6 @@ typedef enum
} InfoMode;
-/**
- * Return the GL enum name for a numeric value.
- * We really only care about the compressed texture formats for now.
- */
-static const char *
-enum_name(GLenum val)
-{
- static const struct {
- const char *name;
- GLenum val;
- } enums [] = {
- { GL_COMPRESSED_ALPHA, 0x84E9 },
- { GL_COMPRESSED_LUMINANCE, 0x84EA },
- { GL_COMPRESSED_LUMINANCE_ALPHA, 0x84EB },
- { GL_COMPRESSED_INTENSITY, 0x84EC },
- { GL_COMPRESSED_RGB, 0x84ED },
- { GL_COMPRESSED_RGBA, 0x84EE },
- { GL_COMPRESSED_TEXTURE_FORMATS, 0x86A3 },
- { GL_COMPRESSED_RGB, 0x84ED },
- { GL_COMPRESSED_RGBA, 0x84EE },
- { GL_COMPRESSED_TEXTURE_FORMATS, 0x86A3 },
- { GL_COMPRESSED_ALPHA, 0x84E9 },
- { GL_COMPRESSED_LUMINANCE, 0x84EA },
- { GL_COMPRESSED_LUMINANCE_ALPHA, 0x84EB },
- { GL_COMPRESSED_INTENSITY, 0x84EC },
- { GL_COMPRESSED_SRGB, 0x8C48 },
- { GL_COMPRESSED_SRGB_ALPHA, 0x8C49 },
- { GL_COMPRESSED_SLUMINANCE, 0x8C4A },
- { GL_COMPRESSED_SLUMINANCE_ALPHA, 0x8C4B },
- { GL_COMPRESSED_RED, 0x8225 },
- { GL_COMPRESSED_RG, 0x8226 },
- { GL_COMPRESSED_RED_RGTC1, 0x8DBB },
- { GL_COMPRESSED_SIGNED_RED_RGTC1, 0x8DBC },
- { GL_COMPRESSED_RG_RGTC2, 0x8DBD },
- { GL_COMPRESSED_SIGNED_RG_RGTC2, 0x8DBE },
- { GL_COMPRESSED_RGB8_ETC2, 0x9274 },
- { GL_COMPRESSED_SRGB8_ETC2, 0x9275 },
- { GL_COMPRESSED_RGB8_PUNCHTHROUGH_ALPHA1_ETC2, 0x9276 },
- { GL_COMPRESSED_SRGB8_PUNCHTHROUGH_ALPHA1_ETC2, 0x9277 },
- { GL_COMPRESSED_RGBA8_ETC2_EAC, 0x9278 },
- { GL_COMPRESSED_SRGB8_ALPHA8_ETC2_EAC, 0x9279 },
- { GL_COMPRESSED_R11_EAC, 0x9270 },
- { GL_COMPRESSED_SIGNED_R11_EAC, 0x9271 },
- { GL_COMPRESSED_RG11_EAC, 0x9272 },
- { GL_COMPRESSED_SIGNED_RG11_EAC, 0x9273 },
- { GL_COMPRESSED_ALPHA_ARB, 0x84E9 },
- { GL_COMPRESSED_LUMINANCE_ARB, 0x84EA },
- { GL_COMPRESSED_LUMINANCE_ALPHA_ARB, 0x84EB },
- { GL_COMPRESSED_INTENSITY_ARB, 0x84EC },
- { GL_COMPRESSED_RGB_ARB, 0x84ED },
- { GL_COMPRESSED_RGBA_ARB, 0x84EE },
- { GL_COMPRESSED_TEXTURE_FORMATS_ARB, 0x86A3 },
- { GL_COMPRESSED_RGBA_BPTC_UNORM_ARB, 0x8E8C },
- { GL_COMPRESSED_SRGB_ALPHA_BPTC_UNORM_ARB, 0x8E8D },
- { GL_COMPRESSED_RGB_BPTC_SIGNED_FLOAT_ARB, 0x8E8E },
- { GL_COMPRESSED_RGB_BPTC_UNSIGNED_FLOAT_ARB, 0x8E8F },
- { GL_COMPRESSED_RGBA_ASTC_4x4_KHR, 0x93B0 },
- { GL_COMPRESSED_RGBA_ASTC_5x4_KHR, 0x93B1 },
- { GL_COMPRESSED_RGBA_ASTC_5x5_KHR, 0x93B2 },
- { GL_COMPRESSED_RGBA_ASTC_6x5_KHR, 0x93B3 },
- { GL_COMPRESSED_RGBA_ASTC_6x6_KHR, 0x93B4 },
- { GL_COMPRESSED_RGBA_ASTC_8x5_KHR, 0x93B5 },
- { GL_COMPRESSED_RGBA_ASTC_8x6_KHR, 0x93B6 },
- { GL_COMPRESSED_RGBA_ASTC_8x8_KHR, 0x93B7 },
- { GL_COMPRESSED_RGBA_ASTC_10x5_KHR, 0x93B8 },
- { GL_COMPRESSED_RGBA_ASTC_10x6_KHR, 0x93B9 },
- { GL_COMPRESSED_RGBA_ASTC_10x8_KHR, 0x93BA },
- { GL_COMPRESSED_RGBA_ASTC_10x10_KHR, 0x93BB },
- { GL_COMPRESSED_RGBA_ASTC_12x10_KHR, 0x93BC },
- { GL_COMPRESSED_RGBA_ASTC_12x12_KHR, 0x93BD },
- { GL_COMPRESSED_SRGB8_ALPHA8_ASTC_4x4_KHR, 0x93D0 },
- { GL_COMPRESSED_SRGB8_ALPHA8_ASTC_5x4_KHR, 0x93D1 },
- { GL_COMPRESSED_SRGB8_ALPHA8_ASTC_5x5_KHR, 0x93D2 },
- { GL_COMPRESSED_SRGB8_ALPHA8_ASTC_6x5_KHR, 0x93D3 },
- { GL_COMPRESSED_SRGB8_ALPHA8_ASTC_6x6_KHR, 0x93D4 },
- { GL_COMPRESSED_SRGB8_ALPHA8_ASTC_8x5_KHR, 0x93D5 },
- { GL_COMPRESSED_SRGB8_ALPHA8_ASTC_8x6_KHR, 0x93D6 },
- { GL_COMPRESSED_SRGB8_ALPHA8_ASTC_8x8_KHR, 0x93D7 },
- { GL_COMPRESSED_SRGB8_ALPHA8_ASTC_10x5_KHR, 0x93D8 },
- { GL_COMPRESSED_SRGB8_ALPHA8_ASTC_10x6_KHR, 0x93D9 },
- { GL_COMPRESSED_SRGB8_ALPHA8_ASTC_10x8_KHR, 0x93DA },
- { GL_COMPRESSED_SRGB8_ALPHA8_ASTC_10x10_KHR, 0x93DB },
-
Re: [Mesa-dev] [PATCH 2/2] wglinfo: use common code from glinfo_common.c
I'm not a cmake expert so I'm not sure my changes to CMakeLists.txt are
ideal. Doing ../somewhere always feels like a hack.
-Brian
On 05/22/2014 08:53 PM, Brian Paul wrote:
---
src/wgl/CMakeLists.txt |3 +-
src/wgl/wglinfo.c | 532 ++--
2 files changed, 18 insertions(+), 517 deletions(-)
diff --git a/src/wgl/CMakeLists.txt b/src/wgl/CMakeLists.txt
index a32a664..d45cbf3 100644
--- a/src/wgl/CMakeLists.txt
+++ b/src/wgl/CMakeLists.txt
@@ -1,6 +1,7 @@
include_directories (
${OPENGL_INCLUDE_PATH}
${GLEW_INCLUDE_DIR}
+ ../xdemos
)
link_libraries (
@@ -12,7 +13,7 @@ add_executable (wglthreads wglthreads.c)
add_executable (wgl_sharedtex_mt sharedtex_mt.c)
set_target_properties (wgl_sharedtex_mt PROPERTIES OUTPUT_NAME sharedtex_mt)
-add_executable (wglinfo wglinfo.c)
+add_executable (wglinfo wglinfo.c ../xdemos/glinfo_common.c)
add_executable (wglcontext wglcontext.c)
add_executable (wincopy WIN32 wincopy.c wglutil.c)
diff --git a/src/wgl/wglinfo.c b/src/wgl/wglinfo.c
index b54c3b6..2b2c921 100644
--- a/src/wgl/wglinfo.c
+++ b/src/wgl/wglinfo.c
@@ -39,6 +39,7 @@
#include stdio.h
#include string.h
#include stdlib.h
+#include glinfo_common.h
typedef enum
@@ -49,520 +50,6 @@ typedef enum
} InfoMode;
-/**
- * Return the GL enum name for a numeric value.
- * We really only care about the compressed texture formats for now.
- */
-static const char *
-enum_name(GLenum val)
-{
- static const struct {
- const char *name;
- GLenum val;
- } enums [] = {
- { GL_COMPRESSED_ALPHA, 0x84E9 },
- { GL_COMPRESSED_LUMINANCE, 0x84EA },
- { GL_COMPRESSED_LUMINANCE_ALPHA, 0x84EB },
- { GL_COMPRESSED_INTENSITY, 0x84EC },
- { GL_COMPRESSED_RGB, 0x84ED },
- { GL_COMPRESSED_RGBA, 0x84EE },
- { GL_COMPRESSED_TEXTURE_FORMATS, 0x86A3 },
- { GL_COMPRESSED_RGB, 0x84ED },
- { GL_COMPRESSED_RGBA, 0x84EE },
- { GL_COMPRESSED_TEXTURE_FORMATS, 0x86A3 },
- { GL_COMPRESSED_ALPHA, 0x84E9 },
- { GL_COMPRESSED_LUMINANCE, 0x84EA },
- { GL_COMPRESSED_LUMINANCE_ALPHA, 0x84EB },
- { GL_COMPRESSED_INTENSITY, 0x84EC },
- { GL_COMPRESSED_SRGB, 0x8C48 },
- { GL_COMPRESSED_SRGB_ALPHA, 0x8C49 },
- { GL_COMPRESSED_SLUMINANCE, 0x8C4A },
- { GL_COMPRESSED_SLUMINANCE_ALPHA, 0x8C4B },
- { GL_COMPRESSED_RED, 0x8225 },
- { GL_COMPRESSED_RG, 0x8226 },
- { GL_COMPRESSED_RED_RGTC1, 0x8DBB },
- { GL_COMPRESSED_SIGNED_RED_RGTC1, 0x8DBC },
- { GL_COMPRESSED_RG_RGTC2, 0x8DBD },
- { GL_COMPRESSED_SIGNED_RG_RGTC2, 0x8DBE },
- { GL_COMPRESSED_RGB8_ETC2, 0x9274 },
- { GL_COMPRESSED_SRGB8_ETC2, 0x9275 },
- { GL_COMPRESSED_RGB8_PUNCHTHROUGH_ALPHA1_ETC2, 0x9276 },
- { GL_COMPRESSED_SRGB8_PUNCHTHROUGH_ALPHA1_ETC2, 0x9277 },
- { GL_COMPRESSED_RGBA8_ETC2_EAC, 0x9278 },
- { GL_COMPRESSED_SRGB8_ALPHA8_ETC2_EAC, 0x9279 },
- { GL_COMPRESSED_R11_EAC, 0x9270 },
- { GL_COMPRESSED_SIGNED_R11_EAC, 0x9271 },
- { GL_COMPRESSED_RG11_EAC, 0x9272 },
- { GL_COMPRESSED_SIGNED_RG11_EAC, 0x9273 },
- { GL_COMPRESSED_ALPHA_ARB, 0x84E9 },
- { GL_COMPRESSED_LUMINANCE_ARB, 0x84EA },
- { GL_COMPRESSED_LUMINANCE_ALPHA_ARB, 0x84EB },
- { GL_COMPRESSED_INTENSITY_ARB, 0x84EC },
- { GL_COMPRESSED_RGB_ARB, 0x84ED },
- { GL_COMPRESSED_RGBA_ARB, 0x84EE },
- { GL_COMPRESSED_TEXTURE_FORMATS_ARB, 0x86A3 },
- { GL_COMPRESSED_RGBA_BPTC_UNORM_ARB, 0x8E8C },
- { GL_COMPRESSED_SRGB_ALPHA_BPTC_UNORM_ARB, 0x8E8D },
- { GL_COMPRESSED_RGB_BPTC_SIGNED_FLOAT_ARB, 0x8E8E },
- { GL_COMPRESSED_RGB_BPTC_UNSIGNED_FLOAT_ARB, 0x8E8F },
- { GL_COMPRESSED_RGBA_ASTC_4x4_KHR, 0x93B0 },
- { GL_COMPRESSED_RGBA_ASTC_5x4_KHR, 0x93B1 },
- { GL_COMPRESSED_RGBA_ASTC_5x5_KHR, 0x93B2 },
- { GL_COMPRESSED_RGBA_ASTC_6x5_KHR, 0x93B3 },
- { GL_COMPRESSED_RGBA_ASTC_6x6_KHR, 0x93B4 },
- { GL_COMPRESSED_RGBA_ASTC_8x5_KHR, 0x93B5 },
- { GL_COMPRESSED_RGBA_ASTC_8x6_KHR, 0x93B6 },
- { GL_COMPRESSED_RGBA_ASTC_8x8_KHR, 0x93B7 },
- { GL_COMPRESSED_RGBA_ASTC_10x5_KHR, 0x93B8 },
- { GL_COMPRESSED_RGBA_ASTC_10x6_KHR, 0x93B9 },
- { GL_COMPRESSED_RGBA_ASTC_10x8_KHR, 0x93BA },
- { GL_COMPRESSED_RGBA_ASTC_10x10_KHR, 0x93BB },
- { GL_COMPRESSED_RGBA_ASTC_12x10_KHR, 0x93BC },
- { GL_COMPRESSED_RGBA_ASTC_12x12_KHR, 0x93BD },
- { GL_COMPRESSED_SRGB8_ALPHA8_ASTC_4x4_KHR, 0x93D0 },
- { GL_COMPRESSED_SRGB8_ALPHA8_ASTC_5x4_KHR, 0x93D1 },
- { GL_COMPRESSED_SRGB8_ALPHA8_ASTC_5x5_KHR, 0x93D2 },
- { GL_COMPRESSED_SRGB8_ALPHA8_ASTC_6x5_KHR, 0x93D3 },
- { GL_COMPRESSED_SRGB8_ALPHA8_ASTC_6x6_KHR, 0x93D4 },
- { GL_COMPRESSED_SRGB8_ALPHA8_ASTC_8x5_KHR, 0x93D5 },
- { GL_COMPRESSED_SRGB8_ALPHA8_ASTC_8x6_KHR, 0x93D6 },
- { GL_COMPRESSED_SRGB8_ALPHA8_ASTC_8x8_KHR, 0x93D7 },
- { GL_COMPRESSED_SRGB8_ALPHA8_ASTC_10x5_KHR, 0x93D8
[Mesa-dev] [Bug 79098] New: x86/common_x86.c:51:19: error: cpuid.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=79098 Priority: medium Bug ID: 79098 Keywords: regression CC: matts...@gmail.com Assignee: mesa-dev@lists.freedesktop.org Summary: x86/common_x86.c:51:19: error: cpuid.h: No such file or directory Severity: blocker Classification: Unclassified OS: Linux (All) Reporter: v...@freedesktop.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Mesa core Product: Mesa mesa: f50361cce79beb78119d835b7a52c0c790d74077 (master 10.3.0-devel) Build error with GCC 4.1. CC common_x86.lo x86/common_x86.c:51:19: error: cpuid.h: No such file or directory commit 8b9302f2b4b0536abb91cb73682ec13640fe9eaf Author: Matt Turner matts...@gmail.com Date: Fri May 2 12:10:17 2014 -0700 mesa/x86: Support SSE 4.1 detection on x86-64. Uses the cpuid.h header provided by gcc and clang. Other platforms are encouraged to switch. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 79095] x86/common_x86.c:348:14: error: use of undeclared identifier 'bit_SSE4_1'
https://bugs.freedesktop.org/show_bug.cgi?id=79095 --- Comment #1 from Matt Turner matts...@gmail.com --- Great. Clang's macro is named wrong. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/10] glsl: parser changes for GL_ARB_explicit_uniform_location
On 05/21/2014 07:52 PM, Ian Romanick wrote:
On 05/21/2014 08:11 AM, Tapani wrote:
On 05/21/2014 05:43 PM, Tapani wrote:
On 05/21/2014 01:27 AM, Ian Romanick wrote:
On 05/19/2014 10:08 PM, Tapani wrote:
On 05/19/2014 08:18 PM, Ian Romanick wrote:
On 04/09/2014 02:56 AM, Tapani Pälli wrote:
diff --git a/src/glsl/glsl_parser_extras.h
b/src/glsl/glsl_parser_extras.h
index c53c583..20879a0 100644
--- a/src/glsl/glsl_parser_extras.h
+++ b/src/glsl/glsl_parser_extras.h
@@ -152,6 +152,20 @@ struct _mesa_glsl_parse_state {
return true;
}
+ bool check_explicit_uniform_location_allowed(YYLTYPE *locp,
+const ir_variable
*var)
+ {
+ /* Requires OpenGL 3.3 or ARB_explicit_attrib_location. */
+ if (ctx-Version 33
!ctx-Extensions.ARB_explicit_attrib_location) {
+ _mesa_glsl_error(locp, this, %s explicit location
requires
+ GL_ARB_explicit_attrib_location extension
+ or OpenGL 3.3, mode_string(var));
Many copy-and-paste bugs. :) Explicit uniform locations aren't added
until 4.3.
It may look copy-paste but the specification states that Requires
OpenGL 3.3 or ARB_explicit_attrib_location:
https://www.opengl.org/registry/specs/ARB/explicit_uniform_location.txt
Using 4.3 capable driver will pass this check correctly.
Oh right, because it relies on 3.3 or ARB_explicit_attib_location to
add the layout keyword. Some comments explaining that this isn't a
copy-and-paste bug will prevent the next person from also thinking that
it is. :)
But this code should check the version (and extension) bits set in the
shader, not what's enabled in the context. How about:
bool check_explicit_attrib_location_allowed(YYLTYPE *locp,
const ir_variable *var)
{
if (!this-has_explicit_attrib_location() ||
!this-ARB_explicit_uniform_location_enable) {
_mesa_glsl_error(locp, this,
uniform explicit location requires
GL_ARB_explicit_uniform_location and
either
GL_ARB_explicit_attrib_location or GLSL
330.);
return false;
}
return true;
}
Sure, this is fine by me. I'll send new patches soon.
Or maybe fine with some changes since my piglit tests won't pass with
this change (for those explicit attrib location is not available for
some reason (!)), will take a look.
Do the tests enable it via #extension?
They enable GL_ARB_explicit_uniform_location but not
GL_ARB_explicit_attrib_location and I think that is the way it should
work. I don't understand why checking the existence of
explicit_attrib_location from context is not correct way to deal with
this? It doesn't need to be enabled in the language as layout token will
be there also if just explicit_uniform_location is enabled.
// Tapani
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
