[Mesa3d-dev] [patch] i965: support for sin and cos in vertex shaders
The sin() and cos() functions used to be available only in ARB_fragment_program and not ARB_vertex_program. However, they are perfectly valid in GLSL 1.10 (and later) vertex shaders. Attached patch fixes this for the i965 driver. Regards, -- Sam. >From 3fa30751182420c39daf32a57193b6518e9ca3d2 Mon Sep 17 00:00:00 2001 From: Sam Hocevar <[EMAIL PROTECTED]> Date: Thu, 25 Sep 2008 10:49:05 +0200 Subject: [PATCH] i965: support for sin() and cos() in vertex shaders. --- src/mesa/drivers/dri/i965/brw_vs_emit.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_vs_emit.c b/src/mesa/drivers/dri/i965/brw_vs_emit.c index b0b0449..9de0540 100644 --- a/src/mesa/drivers/dri/i965/brw_vs_emit.c +++ b/src/mesa/drivers/dri/i965/brw_vs_emit.c @@ -1024,6 +1024,9 @@ void brw_vs_emit(struct brw_vs_compile *c ) case OPCODE_ADD: brw_ADD(p, dst, args[0], args[1]); break; + case OPCODE_COS: + emit_math1(c, BRW_MATH_FUNCTION_COS, dst, args[0], BRW_MATH_PRECISION_FULL); + break; case OPCODE_DP3: brw_DP3(p, dst, args[0], args[1]); break; @@ -1089,6 +1092,9 @@ void brw_vs_emit(struct brw_vs_compile *c ) case OPCODE_SEQ: emit_seq(p, dst, args[0], args[1]); break; + case OPCODE_SIN: + emit_math1(c, BRW_MATH_FUNCTION_SIN, dst, args[0], BRW_MATH_PRECISION_FULL); + break; case OPCODE_SNE: emit_sne(p, dst, args[0], args[1]); break; -- 1.5.6.5 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [patch] more meaningful message in i965
On Tue, Sep 23, 2008, Sam Hocevar wrote:
>I find it rather difficult to debug the i965 code generator. Attached
> is a trivial patch that makes one of the errors a bit more helpful.
Here is an updated one that also fixes the obscure message in
brw_wm_emit.c.
--
Sam.
>From 1c7b104002902256cdaf7a8001470a4bf04d199f Mon Sep 17 00:00:00 2001
From: Sam Hocevar <[EMAIL PROTECTED]>
Date: Tue, 23 Sep 2008 17:56:19 +0200
Subject: [PATCH] i965: more meaningful message for unsupported opcodes.
---
src/mesa/drivers/dri/i965/brw_vs_emit.c |5 -
src/mesa/drivers/dri/i965/brw_wm_emit.c |6 --
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vs_emit.c b/src/mesa/drivers/dri/i965/brw_vs_emit.c
index 8759826..b0b0449 100644
--- a/src/mesa/drivers/dri/i965/brw_vs_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_vs_emit.c
@@ -1155,7 +1155,10 @@ void brw_vs_emit(struct brw_vs_compile *c )
case OPCODE_ENDSUB:
break;
default:
- _mesa_printf("Unsupport opcode %d in vertex shader\n", inst->Opcode);
+ _mesa_printf("Unsupported opcode %i (%s) in vertex shader\n",
+ inst->Opcode, inst->Opcode < MAX_OPCODE ?
+_mesa_opcode_string(inst->Opcode) :
+"unknown");
break;
}
diff --git a/src/mesa/drivers/dri/i965/brw_wm_emit.c b/src/mesa/drivers/dri/i965/brw_wm_emit.c
index f1c14c9..ab73563 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_emit.c
@@ -1302,8 +1302,10 @@ void brw_wm_emit( struct brw_wm_compile *c )
break;
default:
- _mesa_printf("unsupport opcode %d in fragment program\n",
- inst->opcode);
+ _mesa_printf("Unsupported opcode %i (%s) in fragment shader\n",
+ inst->opcode, inst->opcode < MAX_OPCODE ?
+_mesa_opcode_string(inst->opcode) :
+"unknown");
}
for (i = 0; i < 4; i++)
--
1.5.6.5
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Problem running xeglgear with linux-dri & EGL_DRIVER=egl_softpipe
Yes, i thought so..so i tried to link libmesa.a in src/gallium/winsys/egl_xlib/Makefile.But then i ran into more interesting problem, i am not sure whether any one has faced it before, but i think it is a serious configuration problem.Let me explain it... The file in mesa/src/mesa/glapi/dispatch.h has some code based on #ifdef IN_DRI_DRIVER. The code looks like below... #ifdef IN_DRI_DRIVER Code here #else extern int driDispatchRemapTable[ driDispatchRemapTable_size ]; Some code... #endif This driDispatchRemapTable is defined in mesa/src/mesa/drivers/dri/common/utils.c which js built as part of i915_dri.so. When building with make linux, dispatch.h is built with IN_DRI_DRIVER defined, so it does not require driDispatchRemapTable. But, when building with make linux-dri, dispatch.h is built with IN_DRI_DRIVER not defined, so the #else part is used.So, libmesa.s has undefined variable driDispatchRemapTable.Then now, if i try to link libmesa.a when building egl_softpipe, it gives linking error, because the driDispatchRemapTable definition is available in i915_dri.so, which i am not linking..so it is quite messy here. Regs, Rahaman. -Original Message- From: José Fonseca <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: mesa3d-dev@lists.sourceforge.net Subject: Re: [Mesa3d-dev] Problem running xeglgear with linux-dri & EGL_DRIVER=egl_softpipe Date: Thu, 25 Sep 2008 12:22:13 +0900 On Thu, Sep 18, 2008 at 3:35 PM, <[EMAIL PROTECTED]> wrote: > Adding the subject line... > > Hi, > > I am using mesa gallium-0.1 branch & build the mesa source code with the > linux-dri option. > > Then while running my xeglgear, i have set the macro EGL_DRIVER=egl_softpipe > & i got the following error > > ./progs/egl/xeglgears > EGL_VERSION = 1.4 (Xlib/softpipe) > ./progs/egl/xeglgears: symbol lookup error: > /home/rahaman/Rahaman_Data/mesa/lib/egl_softpipe.so: undefined symbol: > st_create_context > > I have checked that i am using the proper library. > > My first question : Is this a valid configuration to run my xeglgear i.e. > building mesa with linux-dri and then running it with > EGL_DRIVER=egl_softpipe. > > If yes, then upon further investigation i found that mesa/state_tracker > functionality is built as part of libmesa.a which is part of > i915_dri.so.Note that state_tracker functionality is not part of libGL.so > when building DRI, where as it was part of libGL.so when building make > linux. > > Therefore, when i am giving the option as EGL_DRIVER=egl_softpipe, i am not > using i915_dri.so at all & that's why i am not getting the state_tracker > function definition.So, the error shown is justified. > > As per my understanding egl_softpipe is the equivalent s/w > implementation/s_w fallbacks for i915_dri.so, so it should have all the > functionality i915_dri.so has.What is your thoughts..? I'm not familiar with egl, but it seems that libmesa.a should be linked in src/gallium/winsys/egl_xlib/Makefile, but it is not. Also my understanding is that i915_dri.so and egl_softpipe.so are two different kind of drivers. The egl counter part of i915_dri.so is EGL_i915.so which lives in src/gallium/winsys/drm/intel/egl/Makefile Jose - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Recent refactoring broke VTK
Brad King wrote: > Brian Paul wrote: >> Brad, the first thing that'd be useful is a stack trace from the crash point. > > Oops, of course. I had been collecting pieces of information before > sending the email and never cut-and-paste it in. Here is the assertion > failure stack trace: > > #0 0x2adc747e11d5 in raise () from /lib/libc.so.6 > #1 0x2adc747e2680 in abort () from /lib/libc.so.6 > #2 0x2adc747da75f in __assert_fail () from /lib/libc.so.6 > #3 0x2adc72a01c1f in _mesa_HashLookup (table=, > key=) at main/hash.c:133 > #4 0x2adc72a38c6d in _mesa_DeleteTextures (n=1, > textures=0x7fff3d22a208) at main/texobj.c:803 > #5 0x2adc6ddf5c2f in (VTK Code) More recently published changes have broken VTK further: http://www.cdash.org/CDash/viewTest.php?onlyfailed&buildid=180467 I chose the "contoursToSurfacePython" test to track things down this time: http://www.cdash.org/CDash/testDetails.php?test=9894872&build=180467 Test output includes: - *** glibc detected *** /.../bin/vtkpython: double free or corruption (!prev): 0x01224b00 *** === Backtrace: = /lib/libc.so.6[0x2b09530c001d] /lib/libc.so.6(cfree+0x76)[0x2b09530c1d26] /...lib/libMesaGL.so.1(_mesa_delete_buffer_object+0x12)[0x2b094f56f942] /.../lib/libMesaGL.so.1(_mesa_free_context_data+0x107)[0x2b094f571657] /.../lib/libMesaGL.so.1(XMesaDestroyContext+0x29)[0x2b094f52dbf9] /.../Mesa-build/lib/libMesaGL.so.1[0x2b094f521884] (VTK code)... - A backtrace in gdb gives: - #0 0x2b6991bd91d5 in raise () from /lib/libc.so.6 #1 0x2b6991bda680 in abort () from /lib/libc.so.6 #2 0x2b6991c11f4b in __libc_message () from /lib/libc.so.6 #3 0x2b6991c1701d in malloc_printerr () from /lib/libc.so.6 #4 0x2b6991c18d26 in free () from /lib/libc.so.6 #5 0x2b698ef4b942 in _mesa_delete_buffer_object (ctx=, bufObj=0xa72dd0) at main/bufferobj.c:168 #6 0x2b698ef4d657 in _mesa_free_context_data (ctx=0xa7d3c0) at main/context.c:1336 #7 0x2b698ef09bf9 in XMesaDestroyContext (c=0xa7d3c0) at xm_api.c:1657 #8 0x2b698eefd884 in Fake_glXDestroyContext (dpy=, ctx=0x23bf) at fakeglx.c:1654 #9 0x2b698b8136fb in (VTK code) - git bisect reports: - 33fef8be825ee8ec6abc0c2ffd9a3a967d84df88 is first bad commit commit 33fef8be825ee8ec6abc0c2ffd9a3a967d84df88 Author: Keith Whitwell <[EMAIL PROTECTED]> Date: Tue Dec 18 16:56:22 2007 + vbo: unmap and remap immediate vbo before/after each draw. Also use BufferData(NULL) to get fresh storage and avoid synchronous operation where we would have to flush and wait for the fence after each draw because of the map. This will chew through a whole load of buffer space on small draws, so it isn't a proper solution. Need to support a no-fence or append mapping mode to do this right, or use user buffers. - -Brad - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [patch] avoid SIGABRT with shadowed shader variables
As of now, redeclaring a sampler variable causes Mesa to raise
SIGABRT. The attached patch avoids crashing the application and provides
a more helpful error message.
Here is a trivial fragment shader that illustrates the behaviour:
uniform sampler2D foo;
void dostuff(sampler2D foo) { }
void main() { dostuff(foo); }
However, nothing in the spec states that samplers should be
considered different from other variables scope-wise. I therefore don't
really understand why the test was here in the first place (especially
since the few tests I did didn't show any problems with redefining
sampler variables).
--
Sam.
>From 3396bbd304f1b41aeb32c9ae46f80a1cc1aa9ace Mon Sep 17 00:00:00 2001
From: Sam Hocevar <[EMAIL PROTECTED]>
Date: Thu, 25 Sep 2008 14:56:41 +0200
Subject: [PATCH] mesa: prevent the slang code generator from aborting when faced with
a sampler variable redeclaration.
---
src/mesa/shader/slang/slang_codegen.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/src/mesa/shader/slang/slang_codegen.c b/src/mesa/shader/slang/slang_codegen.c
index 7006e86..72a3c0e 100644
--- a/src/mesa/shader/slang/slang_codegen.c
+++ b/src/mesa/shader/slang/slang_codegen.c
@@ -2439,7 +2439,11 @@ _slang_gen_var_decl(slang_assemble_ctx *A, slang_variable *var)
/*assert(!var->declared);*/
var->declared = GL_TRUE;
- assert(!is_sampler_type(&var->type));
+ if(is_sampler_type(&var->type)) {
+ slang_info_log_error(A->log, "redeclaration of sampler '%s'",
+ (char*) var->a_name);
+ return NULL;
+ }
n = new_node0(IR_VAR_DECL);
if (n) {
--
1.5.6.5
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Problem running xeglgear with linux-dri & EGL_DRIVER=egl_softpipe
On Thu, Sep 25, 2008 at 2:38 AM, Mustafizur <[EMAIL PROTECTED]> wrote: > Yes, i thought so..so i tried to link libmesa.a in > src/gallium/winsys/egl_xlib/Makefile.But then i ran into more interesting > problem, i am not sure whether any one has faced it before, but i think it > is a serious configuration problem.Let me explain it... > > The file in mesa/src/mesa/glapi/dispatch.h has some code based on #ifdef > IN_DRI_DRIVER. The code looks like below... > > #ifdef IN_DRI_DRIVER > > Code here > #else > > extern int driDispatchRemapTable[ driDispatchRemapTable_size ]; > > Some code... > #endif > > This driDispatchRemapTable is defined in > mesa/src/mesa/drivers/dri/common/utils.c which js built as part of > i915_dri.so. > > When building with make linux, dispatch.h is built with IN_DRI_DRIVER > defined, so it does not require driDispatchRemapTable. > > But, when building with make linux-dri, dispatch.h is built with > IN_DRI_DRIVER not defined, so the #else part is used. This is backwards. When using `make linux' (on either master or gallium-0.1), IN_DRI_DRIVER should not be defined. When using `make linux-dri' (on either master or gallium-0.1), IN_DRI_DRIVER should be defined. Are you sure your configs aren't messed up? What commit are you working from? -- Dan - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Recent VBO changes break i965
On Wed, Sep 24, 2008 at 2:23 PM, Ian Romanick <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Keith and Eric,
>
> Starting with Mesa commit 33fef8be825ee8ec6abc0c2ffd9a3a967d84df88 I'm
> seeing consistent assertion failures in GEM-based Mesa builds.
> Specifically, I'm seeing:
>
> teapot: intel_buffer_objects.c:247: intel_bufferobj_unmap: Assertion
> `intel_obj' failed.
>
> I haven't really investigated it beyond git-bisect yet. I'm hoping that
> one of you will see something obvious. Thoughts?
Most likely the "Null buffer object" is being mapped/unmapped here.
There are quite a few cases through core mesa where we do checks for
if (bufferObj->Name != 0) {
do things one way, for proper buffer obj's
} else {
do things in a very similar way for the NULL buffer obj (ie
traditional array data)
}
That code is missing in this instance. Note that in almost every case
the NULL bufferobj code is what the regular bufferobj code would
degenerate to if the MapBuffer() call returned NULL.
Ideally core mesa should be able to treat the NULL BufferObject in the
same path as regular bufferobject & not have to special case every
place where it might be used.
Maybe the easiest way to do that would be to add something like a:
void *_mesa_map_buffer_object( GLcontext *ctx, struct gl_buffer_object
*BufferObj, ... )
{
if (BufferObj->Name == 0)
return NULL;
return ctx->Driver.MapBufferObj( ctx, BufferObj, ... );
}
and use that in place of direct calls to the driver function
throughout mesa. There'd be a need to examine each usage to see if
this was safe.
In the meantime, either adding the Name==0 check to the vbo code, or
returning NULL in the driver code would probably fix the issue.
Keith
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Recent refactoring broke VTK
Brian Paul wrote: > Brad, I've committed a fix that should solve this later problem. That works, thanks. > For the first issue (_mesa_HashLookup), it would be helpful if there was > debug info in the stack trace. I replaced "-O3 -g" with "-O0 -g" when building Mesa. Here is the new trace: RenderingCxxTests: main/hash.c:133: _mesa_HashLookup: Assertion `table' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 0x2adcc9934850 (LWP 18944)] 0x2adcc82f71d5 in raise () from /lib/libc.so.6 (gdb) where #0 0x2adcc82f71d5 in raise () from /lib/libc.so.6 #1 0x2adcc82f8680 in abort () from /lib/libc.so.6 #2 0x2adcc82f075f in __assert_fail () from /lib/libc.so.6 #3 0x2adcc6492fe2 in _mesa_HashLookup (table=0x0, key=3) at main/hash.c:133 #4 0x2adcc64e5842 in _mesa_lookup_texture (ctx=0x695ec0, id=3) at main/texobj.c:58 #5 0x2adcc64e7133 in _mesa_DeleteTextures (n=1, textures=0x7fffe97ca7a8) at main/texobj.c:803 #6 0x2adcc1855c2f in (VTK Code) -Brad - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 17777] New: Selection and feedback mode are broken
http://bugs.freedesktop.org/show_bug.cgi?id=1 Summary: Selection and feedback mode are broken Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa3d-dev@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] In the last week or two I have noticed that selection and feedback are broken in both the i965 driver and the software rasterizer (swrast_dri.so). This may be related to bug #17099. It seems like that bug may be specific to r300. This was working fine at least as recently as the last week of July. progs/samples/select does not work, and other GL_SELECT tests also fail. I haven't had a chance to bisect to find out exactly when this broke. We'll probably end up closing this as a duplicate of #17099, but we should do some root-cause analysis first. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
