[Mesa-dev] [Bug 28913] New: [GLSL] allowing two version statements

2010-07-05 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=28913

   Summary: [GLSL] allowing two version statements
   Product: Mesa
   Version: git
  Platform: All
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: gordon@intel.com


Both GLSL 1.10 and 1.20 specs say:
"The #version directive must occur in a shader before anything else, except for
comments and white space."

But glsl/tests/glslparsertest/shaders/CorrectVersion1.V110.frag fails with
below output:

Successfully compiled fragment shader
/GFX/Test/Piglit_ext/piglit/tests/glslparsertest/shaders/CorrectVersion1.V110.frag:
(no compiler output)

Output:
PIGLIT: {'result': 'fail' }


This piglit test case was changed as below with
http://cgit.freedesktop.org/piglit/commit/?id=5752c9a33a66e91544a6af2e926833183318357b

/* Only one version statement is allowed; two should raise an error. */
#version 110
#version 110

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 28913] [GLSL] allowing two version statements

2010-07-05 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=28913

Gordon Jin  changed:

   What|Removed |Added

 CC||kenn...@whitecape.org

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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] [Mesa3d-dev] mesa doesn't work with compiz (i965 + tips of all branches)

2010-07-05 Thread Michel Dänzer 
On Don, 2010-07-01 at 10:32 -0700, Ian Romanick wrote: 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Note: I'm sending this reply to mesa-dev@lists.freedesktop.org instead
> of the old mailing list.
> 
> Maxim Levitsky wrote:
> > On Tue, 2010-06-29 at 15:49 -0700, Ian Romanick wrote:
> > Corbin Simpson wrote:
>  Curious. Admittedly I can't look at the content of that commit, but they
>  can't be too useless if compiz selects them. IIRC the point was to limit
>  the runtime of Intel internal tests; can't those tests be amended
>  instead? The number of configs will only grow; r300g has over 200 now
>  thanks to multisampling.
> > The configs are useless.  Applications can only ask for "bits >= X".
> > There are still 24-bit depth / 8-bit stencil configs, and, last time I
> > checked, 8 >= 0.  There is no way to ask for a 24/0 config that wouldn't
> > instead give a 24/8 config.
> > 
>  Posting from a mobile, pardon my terseness. ~ C.
> 
> > On Jun 29, 2010 1:28 PM, "Maxim Levitsky"  > > wrote:
> >
> > On Tue, 2010-06-29 at 20:34 +0300, Maxim Levitsky wrote:
> >> On Sun, 2010-06-27 at 19:07 +0300, Maxim ...
> > Bisected this to
> >
> > 73e24cd5a7a0760726a681dda5b88805ddcf1555 is first bad commit
> > commit 73e24cd5a7a0760726a681dda5b88805ddcf1555
> > Author: Ian Romanick  > >
> > Date:   Mon Feb 8 10:34:52 2010 -0800
> >
> >intel: Stop exposing useless 24 depth/0 stencil configs
> > I need two pieces of information:
> > 
> >   - A diff of the output of glxinfo immediately before and immediately
> > after this commit.
> > 
> >   - A list of what config attributes compiz is requesting.  It should
> > be easy enough to instrument choose_visual in glxcmds.c to dump out
> > attribList.
> > 
> > It should be pretty easy to root-cause this problem with that data.
> 
> [snip]
> 
> > What is interesting is this:
> >
> > -0x62 32 tc  0 32  0 r  y  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
> 
> Yup.  That has to be it.  The fix will have two parts.  First, make the
> 3D driver a this specific visual.

-ENOPARSE :)

> That will make "new" 3D drivers work with "old" 2D drivers.  Second,
> make the 2D driver mark this visual has having stencil.

The X driver is no longer involved in GLX visuals. (However, the Mesa
driver loaded by the X server is involved. Maxim, did the X server load
your self-built i965_dri.so for each test?)

I think at least part of the problem could be that the X server code was
changed to make the depth 32 GLX visual take the place of one of the
depth 24 ones. It should probably become separate again.


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa3d-dev] mesa doesn't work with compiz (i965 + tips of all branches)

2010-07-05 Thread Maxim Levitsky 
2010/7/5 Michel Dänzer :
> On Don, 2010-07-01 at 10:32 -0700, Ian Romanick wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Note: I'm sending this reply to mesa-dev@lists.freedesktop.org instead
>> of the old mailing list.
>>
>> Maxim Levitsky wrote:
>> > On Tue, 2010-06-29 at 15:49 -0700, Ian Romanick wrote:
>> > Corbin Simpson wrote:
>>  Curious. Admittedly I can't look at the content of that commit, but they
>>  can't be too useless if compiz selects them. IIRC the point was to limit
>>  the runtime of Intel internal tests; can't those tests be amended
>>  instead? The number of configs will only grow; r300g has over 200 now
>>  thanks to multisampling.
>> > The configs are useless.  Applications can only ask for "bits >= X".
>> > There are still 24-bit depth / 8-bit stencil configs, and, last time I
>> > checked, 8 >= 0.  There is no way to ask for a 24/0 config that wouldn't
>> > instead give a 24/8 config.
>> >
>>  Posting from a mobile, pardon my terseness. ~ C.
>> 
>> > On Jun 29, 2010 1:28 PM, "Maxim Levitsky" > > > wrote:
>> >
>> > On Tue, 2010-06-29 at 20:34 +0300, Maxim Levitsky wrote:
>> >> On Sun, 2010-06-27 at 19:07 +0300, Maxim ...
>> > Bisected this to
>> >
>> > 73e24cd5a7a0760726a681dda5b88805ddcf1555 is first bad commit
>> > commit 73e24cd5a7a0760726a681dda5b88805ddcf1555
>> > Author: Ian Romanick > > >
>> > Date:   Mon Feb 8 10:34:52 2010 -0800
>> >
>> >    intel: Stop exposing useless 24 depth/0 stencil configs
>> > I need two pieces of information:
>> >
>> >   - A diff of the output of glxinfo immediately before and immediately
>> >     after this commit.
>> >
>> >   - A list of what config attributes compiz is requesting.  It should
>> >     be easy enough to instrument choose_visual in glxcmds.c to dump out
>> >     attribList.
>> >
>> > It should be pretty easy to root-cause this problem with that data.
>>
>> [snip]
>>
>> > What is interesting is this:
>> >
>> > -0x62 32 tc  0 32  0 r  y  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
>>
>> Yup.  That has to be it.  The fix will have two parts.  First, make the
>> 3D driver a this specific visual.
>
> -ENOPARSE :)
>
>> That will make "new" 3D drivers work with "old" 2D drivers.  Second,
>> make the 2D driver mark this visual has having stencil.
>
> The X driver is no longer involved in GLX visuals. (However, the Mesa
> driver loaded by the X server is involved. Maxim, did the X server load
> your self-built i965_dri.so for each test?)
No. I just compile the mesa (and of course includes i965_dri.so) with
or without commit
change is instant.

However. both good and bad behavior is persistent over X restarts,
when it does load new  i965_dri.so


Wait a minute

(II) AIGLX: Loaded and initialized /usr/local/lib/dri/swrast_dri.so
(II) GLX: Initialized DRISWRAST GL provider for screen 0


I disabled AIGLX in x server long time ago, because it makes me
recompile the server each time mesa changes, and otherwise is useless.

So I try with AIGLX next.

>
> I think at least part of the problem could be that the X server code was
> changed to make the depth 32 GLX visual take the place of one of the
> depth 24 ones. It should probably become separate again.
>
>
> --
> Earthling Michel Dänzer           |                http://www.vmware.com
> Libre software enthusiast         |          Debian, X and DRI developer
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/5] pipebuffer: Use pipe_condvar instead of ifdef'd sys_yield()

2010-07-05 Thread Keith Whitwell 
On Sat, 2010-07-03 at 13:49 -0700, nobled wrote:
> This way there's fewer ifdef's *and* less busy-waiting.
> ---
>  .../auxiliary/pipebuffer/pb_buffer_fenced.c|   19 +++
>  1 files changed, 7 insertions(+), 12 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
> b/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
> index d6cf640..db3617e 100644
> --- a/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
> +++ b/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
> @@ -34,13 +34,6 @@
>   */
> 
> 
> -#include "pipe/p_config.h"
> -
> -#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) || 
> defined(PIPE_OS_SOLARIS)
> -#include 
> -#include 
> -#endif
> -
>  #include "pipe/p_compiler.h"
>  #include "pipe/p_defines.h"
>  #include "util/u_debug.h"
> @@ -81,6 +74,7 @@ struct fenced_manager
>  * Following members are mutable and protected by this mutex.
>  */
> pipe_mutex mutex;
> +   pipe_condvar zero_fenced;
> 
> /**
>  * Fenced buffer list.
> @@ -307,6 +301,8 @@ fenced_buffer_remove_locked(struct fenced_manager
> *fenced_mgr,
> LIST_DEL(&fenced_buf->head);

Noble,

It looks like your mail client is word-wrapping these patches, eg.
"*fenced_mgr," above.  Can you figure out a way to send patches without
this -- eg git send-email ?

Keith

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa3d-dev] mesa doesn't work with compiz (i965 + tips of all branches)

2010-07-05 Thread Maxim Levitsky 
On Mon, 2010-07-05 at 13:08 +0300, Maxim Levitsky wrote:
> 2010/7/5 Michel Dänzer :
> > On Don, 2010-07-01 at 10:32 -0700, Ian Romanick wrote:
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> Note: I'm sending this reply to mesa-dev@lists.freedesktop.org instead
> >> of the old mailing list.
> >>
> >> Maxim Levitsky wrote:
> >> > On Tue, 2010-06-29 at 15:49 -0700, Ian Romanick wrote:
> >> > Corbin Simpson wrote:
> >>  Curious. Admittedly I can't look at the content of that commit, but 
> >>  they
> >>  can't be too useless if compiz selects them. IIRC the point was to 
> >>  limit
> >>  the runtime of Intel internal tests; can't those tests be amended
> >>  instead? The number of configs will only grow; r300g has over 200 now
> >>  thanks to multisampling.
> >> > The configs are useless.  Applications can only ask for "bits >= X".
> >> > There are still 24-bit depth / 8-bit stencil configs, and, last time I
> >> > checked, 8 >= 0.  There is no way to ask for a 24/0 config that wouldn't
> >> > instead give a 24/8 config.
> >> >
> >>  Posting from a mobile, pardon my terseness. ~ C.
> >> 
> >> > On Jun 29, 2010 1:28 PM, "Maxim Levitsky"  >> > > wrote:
> >> >
> >> > On Tue, 2010-06-29 at 20:34 +0300, Maxim Levitsky wrote:
> >> >> On Sun, 2010-06-27 at 19:07 +0300, Maxim ...
> >> > Bisected this to
> >> >
> >> > 73e24cd5a7a0760726a681dda5b88805ddcf1555 is first bad commit
> >> > commit 73e24cd5a7a0760726a681dda5b88805ddcf1555
> >> > Author: Ian Romanick  >> > >
> >> > Date:   Mon Feb 8 10:34:52 2010 -0800
> >> >
> >> >intel: Stop exposing useless 24 depth/0 stencil configs
> >> > I need two pieces of information:
> >> >
> >> >   - A diff of the output of glxinfo immediately before and immediately
> >> > after this commit.
> >> >
> >> >   - A list of what config attributes compiz is requesting.  It should
> >> > be easy enough to instrument choose_visual in glxcmds.c to dump out
> >> > attribList.
> >> >
> >> > It should be pretty easy to root-cause this problem with that data.
> >>
> >> [snip]
> >>
> >> > What is interesting is this:
> >> >
> >> > -0x62 32 tc  0 32  0 r  y  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
> >>
> >> Yup.  That has to be it.  The fix will have two parts.  First, make the
> >> 3D driver a this specific visual.
> >
> > -ENOPARSE :)
> >
> >> That will make "new" 3D drivers work with "old" 2D drivers.  Second,
> >> make the 2D driver mark this visual has having stencil.
> >
> > The X driver is no longer involved in GLX visuals. (However, the Mesa
> > driver loaded by the X server is involved. Maxim, did the X server load
> > your self-built i965_dri.so for each test?)
> No. I just compile the mesa (and of course includes i965_dri.so) with
> or without commit
> change is instant.
> 
> However. both good and bad behavior is persistent over X restarts,
> when it does load new  i965_dri.so
> 
> 
> Wait a minute
> 
> (II) AIGLX: Loaded and initialized /usr/local/lib/dri/swrast_dri.so
> (II) GLX: Initialized DRISWRAST GL provider for screen 0
> 
> 
> I disabled AIGLX in x server long time ago, because it makes me
> recompile the server each time mesa changes, and otherwise is useless.
> 
> So I try with AIGLX next.



So thats was it, yep, server without --disable-aiglx works just fine
with unpached mesa...

This still should be fixed, because --disable-aiglx helps debbuging a
lot by decoupling xserver and mesa.


Best regards,
Maxim Levitsky



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Intel-gfx] [Mesa3d-dev] mesa doesn't work with compiz (i965 + tips of all branches)

2010-07-05 Thread Kristian Høgsberg 
2010/7/5 Maxim Levitsky :
> On Mon, 2010-07-05 at 13:08 +0300, Maxim Levitsky wrote:
>> 2010/7/5 Michel Dänzer :
>> > On Don, 2010-07-01 at 10:32 -0700, Ian Romanick wrote:
>> >> -BEGIN PGP SIGNED MESSAGE-
>> >> Hash: SHA1
>> >>
>> >> Note: I'm sending this reply to mesa-dev@lists.freedesktop.org instead
>> >> of the old mailing list.
>> >>
>> >> Maxim Levitsky wrote:
>> >> > On Tue, 2010-06-29 at 15:49 -0700, Ian Romanick wrote:
>> >> > Corbin Simpson wrote:
>> >>  Curious. Admittedly I can't look at the content of that commit, but 
>> >>  they
>> >>  can't be too useless if compiz selects them. IIRC the point was to 
>> >>  limit
>> >>  the runtime of Intel internal tests; can't those tests be amended
>> >>  instead? The number of configs will only grow; r300g has over 200 now
>> >>  thanks to multisampling.
>> >> > The configs are useless.  Applications can only ask for "bits >= X".
>> >> > There are still 24-bit depth / 8-bit stencil configs, and, last time I
>> >> > checked, 8 >= 0.  There is no way to ask for a 24/0 config that wouldn't
>> >> > instead give a 24/8 config.
>> >> >
>> >>  Posting from a mobile, pardon my terseness. ~ C.
>> >> 
>> >> > On Jun 29, 2010 1:28 PM, "Maxim Levitsky" > >> > > wrote:
>> >> >
>> >> > On Tue, 2010-06-29 at 20:34 +0300, Maxim Levitsky wrote:
>> >> >> On Sun, 2010-06-27 at 19:07 +0300, Maxim ...
>> >> > Bisected this to
>> >> >
>> >> > 73e24cd5a7a0760726a681dda5b88805ddcf1555 is first bad commit
>> >> > commit 73e24cd5a7a0760726a681dda5b88805ddcf1555
>> >> > Author: Ian Romanick > >> > >
>> >> > Date:   Mon Feb 8 10:34:52 2010 -0800
>> >> >
>> >> >    intel: Stop exposing useless 24 depth/0 stencil configs
>> >> > I need two pieces of information:
>> >> >
>> >> >   - A diff of the output of glxinfo immediately before and immediately
>> >> >     after this commit.
>> >> >
>> >> >   - A list of what config attributes compiz is requesting.  It should
>> >> >     be easy enough to instrument choose_visual in glxcmds.c to dump out
>> >> >     attribList.
>> >> >
>> >> > It should be pretty easy to root-cause this problem with that data.
>> >>
>> >> [snip]
>> >>
>> >> > What is interesting is this:
>> >> >
>> >> > -0x62 32 tc  0 32  0 r  y  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
>> >>
>> >> Yup.  That has to be it.  The fix will have two parts.  First, make the
>> >> 3D driver a this specific visual.
>> >
>> > -ENOPARSE :)
>> >
>> >> That will make "new" 3D drivers work with "old" 2D drivers.  Second,
>> >> make the 2D driver mark this visual has having stencil.
>> >
>> > The X driver is no longer involved in GLX visuals. (However, the Mesa
>> > driver loaded by the X server is involved. Maxim, did the X server load
>> > your self-built i965_dri.so for each test?)
>> No. I just compile the mesa (and of course includes i965_dri.so) with
>> or without commit
>> change is instant.
>>
>> However. both good and bad behavior is persistent over X restarts,
>> when it does load new  i965_dri.so
>>
>>
>> Wait a minute
>>
>> (II) AIGLX: Loaded and initialized /usr/local/lib/dri/swrast_dri.so
>> (II) GLX: Initialized DRISWRAST GL provider for screen 0
>>
>>
>> I disabled AIGLX in x server long time ago, because it makes me
>> recompile the server each time mesa changes, and otherwise is useless.
>>
>> So I try with AIGLX next.
>
>
>
> So thats was it, yep, server without --disable-aiglx works just fine
> with unpached mesa...
>
> This still should be fixed, because --disable-aiglx helps debbuging a
> lot by decoupling xserver and mesa.

This hasn't been the case in a long time.  The DRI driver is ABI
stable and always backwards compatible.

Kristian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/5 *fixed*] pipebuffer: Use pipe_condvar instead of ifdef'd sys_yield()

2010-07-05 Thread nobled 
This way there's fewer ifdef's *and* less busy-waiting.
---
 .../auxiliary/pipebuffer/pb_buffer_fenced.c|   19 +++
 1 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
b/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
index d6cf640..db3617e 100644
--- a/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
+++ b/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
@@ -34,13 +34,6 @@
 */


-#include "pipe/p_config.h"
-
-#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) || defined(PIPE_OS_SOLARIS)
-#include 
-#include 
-#endif
-
 #include "pipe/p_compiler.h"
 #include "pipe/p_defines.h"
 #include "util/u_debug.h"
@@ -81,6 +74,7 @@ struct fenced_manager
* Following members are mutable and protected by this mutex.
*/
   pipe_mutex mutex;
+   pipe_condvar zero_fenced;

   /**
* Fenced buffer list.
@@ -307,6 +301,8 @@
   LIST_DEL(&fenced_buf->head);
   assert(fenced_mgr->num_fenced);
   --fenced_mgr->num_fenced;
+   if (fenced_mgr->num_fenced == 0)
+  pipe_condvar_broadcast(fenced_mgr->zero_fenced);

   LIST_ADDTAIL(&fenced_buf->head, &fenced_mgr->unfenced);
   ++fenced_mgr->num_unfenced;
@@ -1008,13 +1004,10 @@ fenced_bufmgr_destroy(struct pb_manager *mgr)

   /* Wait on outstanding fences */
   while (fenced_mgr->num_fenced) {
-  pipe_mutex_unlock(fenced_mgr->mutex);
-#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) || defined(PIPE_OS_SOLARIS)
-  sched_yield();
-#endif
-  pipe_mutex_lock(fenced_mgr->mutex);
  while(fenced_manager_check_signalled_locked(fenced_mgr, TRUE))
 ;
+  if (fenced_mgr->num_fenced)
+ pipe_condvar_wait(fenced_mgr->zero_fenced, fenced_mgr->mutex);
   }

 #ifdef DEBUG
@@ -1023,6 +1016,7 @@ fenced_bufmgr_destroy(struct pb_manager *mgr)

   pipe_mutex_unlock(fenced_mgr->mutex);
   pipe_mutex_destroy(fenced_mgr->mutex);
+   pipe_condvar_destroy(fenced_mgr->zero_fenced);

   if(fenced_mgr->provider)
  fenced_mgr->provider->destroy(fenced_mgr->provider);
@@ -1063,6 +1057,7 @@ fenced_bufmgr_create(struct pb_manager *provider,
   LIST_INITHEAD(&fenced_mgr->unfenced);
   fenced_mgr->num_unfenced = 0;

+   pipe_condvar_init(fenced_mgr->zero_fenced);
   pipe_mutex_init(fenced_mgr->mutex);

   return &fenced_mgr->base;
--
1.5.4.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/5 *really fixed*] pipebuffer: Use pipe_condvar instead of ifdef'd sys_yield()

2010-07-05 Thread nobled 
MIME-Version: 1.0
Sender: dw4nob...@googlemail.com
Received: by 10.227.108.163 with HTTP; Sat, 3 Jul 2010 13:49:13 -0700 (PDT)
Date: Sat, 3 Jul 2010 16:49:13 -0400
Delivered-To: dw4nob...@gmail.com
X-Google-Sender-Auth: eL7Za7A89LOV3Re866Zs5LSae58
Message-ID: 
Subject: [PATCH 3/5] pipebuffer: Use pipe_condvar instead of ifdef'd
sys_yield()
From: nobled 
To: mesa-dev@lists.freedesktop.org
Content-Type: text/plain; charset=UTF-8

This way there's fewer ifdef's *and* less busy-waiting.
---
 .../auxiliary/pipebuffer/pb_buffer_fenced.c|   19 +++
 1 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
b/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
index d6cf640..db3617e 100644
--- a/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
+++ b/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
@@ -34,13 +34,6 @@
  */


-#include "pipe/p_config.h"
-
-#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) || defined(PIPE_OS_SOLARIS)
-#include 
-#include 
-#endif
-
 #include "pipe/p_compiler.h"
 #include "pipe/p_defines.h"
 #include "util/u_debug.h"
@@ -81,6 +74,7 @@ struct fenced_manager
 * Following members are mutable and protected by this mutex.
 */
pipe_mutex mutex;
+   pipe_condvar zero_fenced;

/**
 * Fenced buffer list.
@@ -307,6 +301,8 @@
LIST_DEL(&fenced_buf->head);
assert(fenced_mgr->num_fenced);
--fenced_mgr->num_fenced;
+   if (fenced_mgr->num_fenced == 0)
+  pipe_condvar_broadcast(fenced_mgr->zero_fenced);

LIST_ADDTAIL(&fenced_buf->head, &fenced_mgr->unfenced);
++fenced_mgr->num_unfenced;
@@ -1008,13 +1004,10 @@ fenced_bufmgr_destroy(struct pb_manager *mgr)

/* Wait on outstanding fences */
while (fenced_mgr->num_fenced) {
-  pipe_mutex_unlock(fenced_mgr->mutex);
-#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) || defined(PIPE_OS_SOLARIS)
-  sched_yield();
-#endif
-  pipe_mutex_lock(fenced_mgr->mutex);
   while(fenced_manager_check_signalled_locked(fenced_mgr, TRUE))
  ;
+  if (fenced_mgr->num_fenced)
+ pipe_condvar_wait(fenced_mgr->zero_fenced, fenced_mgr->mutex);
}

 #ifdef DEBUG
@@ -1023,6 +1016,7 @@ fenced_bufmgr_destroy(struct pb_manager *mgr)

pipe_mutex_unlock(fenced_mgr->mutex);
pipe_mutex_destroy(fenced_mgr->mutex);
+   pipe_condvar_destroy(fenced_mgr->zero_fenced);

if(fenced_mgr->provider)
   fenced_mgr->provider->destroy(fenced_mgr->provider);
@@ -1063,6 +1057,7 @@ fenced_bufmgr_create(struct pb_manager *provider,
LIST_INITHEAD(&fenced_mgr->unfenced);
fenced_mgr->num_unfenced = 0;

+   pipe_condvar_init(fenced_mgr->zero_fenced);
pipe_mutex_init(fenced_mgr->mutex);

return &fenced_mgr->base;
-- 
1.5.4.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/5 *really fixed*] pipebuffer: Use pipe_condvar instead of ifdef'd sys_yield()

2010-07-05 Thread nobled 
This way there's fewer ifdef's *and* less busy-waiting.
---
 .../auxiliary/pipebuffer/pb_buffer_fenced.c|   19 +++
 1 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
b/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
index d6cf640..db3617e 100644
--- a/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
+++ b/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
@@ -34,13 +34,6 @@
  */


-#include "pipe/p_config.h"
-
-#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) || defined(PIPE_OS_SOLARIS)
-#include 
-#include 
-#endif
-
 #include "pipe/p_compiler.h"
 #include "pipe/p_defines.h"
 #include "util/u_debug.h"
@@ -81,6 +74,7 @@ struct fenced_manager
 * Following members are mutable and protected by this mutex.
 */
pipe_mutex mutex;
+   pipe_condvar zero_fenced;

/**
 * Fenced buffer list.
@@ -307,6 +301,8 @@
LIST_DEL(&fenced_buf->head);
assert(fenced_mgr->num_fenced);
--fenced_mgr->num_fenced;
+   if (fenced_mgr->num_fenced == 0)
+  pipe_condvar_broadcast(fenced_mgr->zero_fenced);

LIST_ADDTAIL(&fenced_buf->head, &fenced_mgr->unfenced);
++fenced_mgr->num_unfenced;
@@ -1008,13 +1004,10 @@ fenced_bufmgr_destroy(struct pb_manager *mgr)

/* Wait on outstanding fences */
while (fenced_mgr->num_fenced) {
-  pipe_mutex_unlock(fenced_mgr->mutex);
-#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD) || defined(PIPE_OS_SOLARIS)
-  sched_yield();
-#endif
-  pipe_mutex_lock(fenced_mgr->mutex);
   while(fenced_manager_check_signalled_locked(fenced_mgr, TRUE))
  ;
+  if (fenced_mgr->num_fenced)
+ pipe_condvar_wait(fenced_mgr->zero_fenced, fenced_mgr->mutex);
}

 #ifdef DEBUG
@@ -1023,6 +1016,7 @@ fenced_bufmgr_destroy(struct pb_manager *mgr)

pipe_mutex_unlock(fenced_mgr->mutex);
pipe_mutex_destroy(fenced_mgr->mutex);
+   pipe_condvar_destroy(fenced_mgr->zero_fenced);

if(fenced_mgr->provider)
   fenced_mgr->provider->destroy(fenced_mgr->provider);
@@ -1063,6 +1057,7 @@ fenced_bufmgr_create(struct pb_manager *provider,
LIST_INITHEAD(&fenced_mgr->unfenced);
fenced_mgr->num_unfenced = 0;

+   pipe_condvar_init(fenced_mgr->zero_fenced);
pipe_mutex_init(fenced_mgr->mutex);

return &fenced_mgr->base;
-- 
1.5.4.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 28913] [GLSL] allowing two version statements

2010-07-05 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=28913

--- Comment #1 from Kenneth Graunke  2010-07-05 11:14:23 
PDT ---
Right - this is fixed in the glsl2 branch.  Mesa master (incorrectly) allows
this to pass, but the new compiler does not.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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] r300/compiler: Implement KILP opcode.

2010-07-05 Thread Tom Stellard 
---
 src/gallium/drivers/r300/r300_tgsi_to_rc.c |2 +-
 src/mesa/drivers/dri/r300/compiler/r3xx_fragprog.c |4 ++
 .../drivers/dri/r300/compiler/radeon_opcodes.c |4 ++
 .../drivers/dri/r300/compiler/radeon_opcodes.h |3 ++
 .../drivers/dri/r300/compiler/radeon_program_alu.c |   30 
 .../drivers/dri/r300/compiler/radeon_program_alu.h |2 +
 6 files changed, 44 insertions(+), 1 deletions(-)

diff --git a/src/gallium/drivers/r300/r300_tgsi_to_rc.c 
b/src/gallium/drivers/r300/r300_tgsi_to_rc.c
index 5394e04..d31cf7e 100644
--- a/src/gallium/drivers/r300/r300_tgsi_to_rc.c
+++ b/src/gallium/drivers/r300/r300_tgsi_to_rc.c
@@ -71,7 +71,7 @@ static unsigned translate_opcode(unsigned opcode)
 case TGSI_OPCODE_COS: return RC_OPCODE_COS;
 case TGSI_OPCODE_DDX: return RC_OPCODE_DDX;
 case TGSI_OPCODE_DDY: return RC_OPCODE_DDY;
- /* case TGSI_OPCODE_KILP: return RC_OPCODE_KILP; */
+   case TGSI_OPCODE_KILP: return RC_OPCODE_KILP;
  /* case TGSI_OPCODE_PK2H: return RC_OPCODE_PK2H; */
  /* case TGSI_OPCODE_PK2US: return RC_OPCODE_PK2US; */
  /* case TGSI_OPCODE_PK4B: return RC_OPCODE_PK4B; */
diff --git a/src/mesa/drivers/dri/r300/compiler/r3xx_fragprog.c 
b/src/mesa/drivers/dri/r300/compiler/r3xx_fragprog.c
index b53571a..32a369b 100644
--- a/src/mesa/drivers/dri/r300/compiler/r3xx_fragprog.c
+++ b/src/mesa/drivers/dri/r300/compiler/r3xx_fragprog.c
@@ -100,6 +100,10 @@ void r3xx_compile_fragment_program(struct 
r300_fragment_program_compiler* c)
struct emulate_loop_state loop_state;
 
rewrite_depth_out(c);
+   
+   /* This transformation needs to be done before any of the IF
+* instructions are modified. */
+   radeonTransformKILP(&c->Base);
 
debug_program_log(c, "before compilation");
 
diff --git a/src/mesa/drivers/dri/r300/compiler/radeon_opcodes.c 
b/src/mesa/drivers/dri/r300/compiler/radeon_opcodes.c
index 128745a..04f234f 100644
--- a/src/mesa/drivers/dri/r300/compiler/radeon_opcodes.c
+++ b/src/mesa/drivers/dri/r300/compiler/radeon_opcodes.c
@@ -399,6 +399,10 @@ struct rc_opcode_info rc_opcodes[MAX_RC_OPCODE] = {
{
.Opcode = RC_OPCODE_BEGIN_TEX,
.Name = "BEGIN_TEX"
+   },
+   {
+   .Opcode = RC_OPCODE_KILP,
+   .Name = "KILP",
}
 };
 
diff --git a/src/mesa/drivers/dri/r300/compiler/radeon_opcodes.h 
b/src/mesa/drivers/dri/r300/compiler/radeon_opcodes.h
index e103ce5..8b9fa07 100644
--- a/src/mesa/drivers/dri/r300/compiler/radeon_opcodes.h
+++ b/src/mesa/drivers/dri/r300/compiler/radeon_opcodes.h
@@ -199,6 +199,9 @@ typedef enum {
 * can run simultaneously. */
RC_OPCODE_BEGIN_TEX,
 
+   /** Stop execution of the shader (GLSL discard) */
+   RC_OPCODE_KILP,
+
MAX_RC_OPCODE
 } rc_opcode;
 
diff --git a/src/mesa/drivers/dri/r300/compiler/radeon_program_alu.c 
b/src/mesa/drivers/dri/r300/compiler/radeon_program_alu.c
index c922d3d..78c2d99 100644
--- a/src/mesa/drivers/dri/r300/compiler/radeon_program_alu.c
+++ b/src/mesa/drivers/dri/r300/compiler/radeon_program_alu.c
@@ -973,3 +973,33 @@ int radeonTransformDeriv(struct radeon_compiler* c,
 
return 1;
 }
+
+/** 
+ * IF Temp[0].x -\ 
+ * KILP - > KIL -Temp[0].x
+ * ENDIF-/
+ *
+ * This needs to be done in its own pass, because it modifies the instructions
+ * before and after KILP.
+ */
+int radeonTransformKILP(struct radeon_compiler * c)
+{
+   struct rc_instruction * inst;
+   for(inst = c->Program.Instructions.Next; 
+   inst != &c->Program.Instructions; inst = inst->Next){
+
+   struct rc_instruction * inst_cond;
+   if(inst->U.I.Opcode != RC_OPCODE_KILP
+   || inst->Prev->U.I.Opcode != RC_OPCODE_IF
+   || inst->Next->U.I.Opcode != RC_OPCODE_ENDIF){
+   continue;
+   }
+   inst->U.I.Opcode = RC_OPCODE_KIL;
+   inst->U.I.SrcReg[0] = negate(inst->Prev->U.I.SrcReg[0]);
+   
+   /* Remove IF */
+   rc_remove_instruction(inst->Prev);
+   /* Remove ENDIF */
+   rc_remove_instruction(inst->Next);
+   }
+}
diff --git a/src/mesa/drivers/dri/r300/compiler/radeon_program_alu.h 
b/src/mesa/drivers/dri/r300/compiler/radeon_program_alu.h
index 77d..4aa084f 100644
--- a/src/mesa/drivers/dri/r300/compiler/radeon_program_alu.h
+++ b/src/mesa/drivers/dri/r300/compiler/radeon_program_alu.h
@@ -60,4 +60,6 @@ int radeonTransformDeriv(
struct rc_instruction * inst,
void*);
 
+int radeonTransformKILP(struct radeon_compiler * c);
+
 #endif /* __RADEON_PROGRAM_ALU_H_ */
-- 
1.7.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 28486] [r300g] Unknown opcode: KILP on R300

2010-07-05 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=28486

--- Comment #1 from Tom Stellard  2010-07-05 13:35:44 PDT 
---
Created an attachment (id=36766)
 View: https://bugs.freedesktop.org/attachment.cgi?id=36766
 Review: https://bugs.freedesktop.org/review?bug=28486&attachment=36766

Implement KILP opcode patch

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 28486] [r300g] Unknown opcode: KILP on R300

2010-07-05 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=28486

Tom Stellard  changed:

   What|Removed |Added

 CC||s...@whiz.se

--- Comment #2 from Tom Stellard  2010-07-05 13:37:47 PDT 
---
*** Bug 28848 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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] Mesa build fails with xlib/egl

2010-07-05 Thread Lionel Landwerlin 
Hello everyone,

I'm trying to build the last Mesa 7.8.2 on top of an Xlib stack.
What I need, is a software implementation of GLES 2.0 with EGL.
This is how I configure Mesa :

./configure --disable-glu --disable-glw --disable-glut --with-driver=xlib 
--with-state-trackers=es,egl --disable-gallium-svga --disable-gallium-intel 
--disable-gallium-radeon --disable-gallium-nouveau --disable-gallium-swrast 
--with-demos=no

Unfortunaltly the build fails near from the end with this error :

...

mklib: Making Linux shared library:  libGLESv2.so.2.0.0
mklib: Installing libGLESv2.so.2.0.0 libGLESv2.so.2 libGLESv2.so in 
../../../../lib64
make[4]: quittant le répertoire « 
/home/djdeath/tmp/pace-xorg/mesa-7.8.2/src/gallium/state_trackers/es »
make[4]: entrant dans le répertoire « 
/home/djdeath/tmp/pace-xorg/mesa-7.8.2/src/gallium/state_trackers/egl »
rm -f depend
touch depend
/usr/bin/makedepend -fdepend -I/usr/lib/gcc/x86_64-linux-gnu/4.4.4/include 
-I/usr/lib/gcc/x86_64-linux-gnu/4.4.4/include-fixed -I. 
-I../../../../src/gallium/include -I../../../../src/gallium/auxiliary 
-I../../../../src/egl/main -I../../../../include 
-I../../../../src/gallium/drivers -I../../../../src/glx -I../../../../src/mesa  
-I/opt/pace-xorg/include/libdrm   -I/opt/pace-xorg/include/libdrm   
common/egl_g3d.c common/egl_g3d_image.c common/egl_st.c x11/glxinit.c 
x11/native_dri2.c x11/native_x11.c x11/native_ximage.c x11/sw_winsys.c 
x11/x11_screen.c ../../../../src/glx/dri2.c kms/native_kms.c 2> /dev/null
make[4]: quittant le répertoire « 
/home/djdeath/tmp/pace-xorg/mesa-7.8.2/src/gallium/state_trackers/egl »
make[4]: entrant dans le répertoire « 
/home/djdeath/tmp/pace-xorg/mesa-7.8.2/src/gallium/state_trackers/egl »
gcc -c -I. -I../../../../src/gallium/include 
-I../../../../src/gallium/auxiliary -I../../../../src/egl/main 
-I../../../../include -I../../../../src/gallium/drivers -I../../../../src/glx 
-I../../../../src/mesa  -I/opt/pace-xorg/include/libdrm   -D_GNU_SOURCE 
-DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XSHM -g -O2 -Wall -Wmissing-prototypes 
-std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing  -fPIC  
-DUSE_X86_64_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XSHM 
x11/glxinit.c -o x11/glxinit.o
x11/glxinit.c:56: warning: no previous prototype for ‘__glXFindDisplay’
x11/glxinit.c: In function ‘AllocAndFetchScreenConfigs’:
x11/glxinit.c:608: error: ‘__GLXscreenConfigs’ has no member named ‘scr’
x11/glxinit.c:609: error: ‘__GLXscreenConfigs’ has no member named ‘dpy’
make[4]: *** [x11/glxinit.o] Erreur 1
make[4]: quittant le répertoire « 
/home/djdeath/tmp/pace-xorg/mesa-7.8.2/src/gallium/state_trackers/egl »
make[3]: *** [subdirs] Erreur 1
make[3]: quittant le répertoire « 
/home/djdeath/tmp/pace-xorg/mesa-7.8.2/src/gallium/state_trackers »
make[2]: *** [default] Erreur 1
make[2]: quittant le répertoire « 
/home/djdeath/tmp/pace-xorg/mesa-7.8.2/src/gallium »
make[1]: *** [subdirs] Erreur 1
make[1]: quittant le répertoire « /home/djdeath/tmp/pace-xorg/mesa-7.8.2/src »
make: *** [default] Erreur 1

Maybe all of this is the result of a misconfiguration on my side, so any
help on this problem is welcome.

Regards,

-- 
Lionel Landwerlin


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa demos w/o Mesa?

2010-07-05 Thread Brian Paul 

tom fogal wrote:

Are the demos supposed to be usable without Mesa?

The 7.8.2 tarball seems to be missing progs/util.  In particular,
this means it is missing progs/util/shaderutil*, and thus many of the
progs/glsl programs cannot compile.



In the past, the MesaDemos package required the MesaLib package.
I'll fix up the 7.8.x Makefile to put progs/util in the former instead 
of the later.


Now that the Mesa demos are in a separate repo with their own 
automake, they shouldn't depend on the rest of Mesa.


-Brian

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] r300/compiler: Implement KILP opcode.

2010-07-05 Thread Marek Olšák 
1. There are trailing whitespaces.

2. I would rather use Negate(Abs(cond)) in case we get negative numbers
there.

-Marek

On Mon, Jul 5, 2010 at 10:01 PM, Tom Stellard  wrote:

> ---
>  src/gallium/drivers/r300/r300_tgsi_to_rc.c |2 +-
>  src/mesa/drivers/dri/r300/compiler/r3xx_fragprog.c |4 ++
>  .../drivers/dri/r300/compiler/radeon_opcodes.c |4 ++
>  .../drivers/dri/r300/compiler/radeon_opcodes.h |3 ++
>  .../drivers/dri/r300/compiler/radeon_program_alu.c |   30
> 
>  .../drivers/dri/r300/compiler/radeon_program_alu.h |2 +
>  6 files changed, 44 insertions(+), 1 deletions(-)
>
> diff --git a/src/gallium/drivers/r300/r300_tgsi_to_rc.c
> b/src/gallium/drivers/r300/r300_tgsi_to_rc.c
> index 5394e04..d31cf7e 100644
> --- a/src/gallium/drivers/r300/r300_tgsi_to_rc.c
> +++ b/src/gallium/drivers/r300/r300_tgsi_to_rc.c
> @@ -71,7 +71,7 @@ static unsigned translate_opcode(unsigned opcode)
> case TGSI_OPCODE_COS: return RC_OPCODE_COS;
> case TGSI_OPCODE_DDX: return RC_OPCODE_DDX;
> case TGSI_OPCODE_DDY: return RC_OPCODE_DDY;
> - /* case TGSI_OPCODE_KILP: return RC_OPCODE_KILP; */
> +   case TGSI_OPCODE_KILP: return RC_OPCODE_KILP;
>  /* case TGSI_OPCODE_PK2H: return RC_OPCODE_PK2H; */
>  /* case TGSI_OPCODE_PK2US: return RC_OPCODE_PK2US; */
>  /* case TGSI_OPCODE_PK4B: return RC_OPCODE_PK4B; */
> diff --git a/src/mesa/drivers/dri/r300/compiler/r3xx_fragprog.c
> b/src/mesa/drivers/dri/r300/compiler/r3xx_fragprog.c
> index b53571a..32a369b 100644
> --- a/src/mesa/drivers/dri/r300/compiler/r3xx_fragprog.c
> +++ b/src/mesa/drivers/dri/r300/compiler/r3xx_fragprog.c
> @@ -100,6 +100,10 @@ void r3xx_compile_fragment_program(struct
> r300_fragment_program_compiler* c)
>struct emulate_loop_state loop_state;
>
>rewrite_depth_out(c);
> +
> +   /* This transformation needs to be done before any of the IF
> +* instructions are modified. */
> +   radeonTransformKILP(&c->Base);
>
>debug_program_log(c, "before compilation");
>
> diff --git a/src/mesa/drivers/dri/r300/compiler/radeon_opcodes.c
> b/src/mesa/drivers/dri/r300/compiler/radeon_opcodes.c
> index 128745a..04f234f 100644
> --- a/src/mesa/drivers/dri/r300/compiler/radeon_opcodes.c
> +++ b/src/mesa/drivers/dri/r300/compiler/radeon_opcodes.c
> @@ -399,6 +399,10 @@ struct rc_opcode_info rc_opcodes[MAX_RC_OPCODE] = {
>{
>.Opcode = RC_OPCODE_BEGIN_TEX,
>.Name = "BEGIN_TEX"
> +   },
> +   {
> +   .Opcode = RC_OPCODE_KILP,
> +   .Name = "KILP",
>}
>  };
>
> diff --git a/src/mesa/drivers/dri/r300/compiler/radeon_opcodes.h
> b/src/mesa/drivers/dri/r300/compiler/radeon_opcodes.h
> index e103ce5..8b9fa07 100644
> --- a/src/mesa/drivers/dri/r300/compiler/radeon_opcodes.h
> +++ b/src/mesa/drivers/dri/r300/compiler/radeon_opcodes.h
> @@ -199,6 +199,9 @@ typedef enum {
> * can run simultaneously. */
>RC_OPCODE_BEGIN_TEX,
>
> +   /** Stop execution of the shader (GLSL discard) */
> +   RC_OPCODE_KILP,
> +
>MAX_RC_OPCODE
>  } rc_opcode;
>
> diff --git a/src/mesa/drivers/dri/r300/compiler/radeon_program_alu.c
> b/src/mesa/drivers/dri/r300/compiler/radeon_program_alu.c
> index c922d3d..78c2d99 100644
> --- a/src/mesa/drivers/dri/r300/compiler/radeon_program_alu.c
> +++ b/src/mesa/drivers/dri/r300/compiler/radeon_program_alu.c
> @@ -973,3 +973,33 @@ int radeonTransformDeriv(struct radeon_compiler* c,
>
>return 1;
>  }
> +
> +/**
> + * IF Temp[0].x -\
> + * KILP - > KIL -Temp[0].x
> + * ENDIF-/
> + *
> + * This needs to be done in its own pass, because it modifies the
> instructions
> + * before and after KILP.
> + */
> +int radeonTransformKILP(struct radeon_compiler * c)
> +{
> +   struct rc_instruction * inst;
> +   for(inst = c->Program.Instructions.Next;
> +   inst != &c->Program.Instructions; inst =
> inst->Next){
> +
> +   struct rc_instruction * inst_cond;
> +   if(inst->U.I.Opcode != RC_OPCODE_KILP
> +   || inst->Prev->U.I.Opcode != RC_OPCODE_IF
> +   || inst->Next->U.I.Opcode != RC_OPCODE_ENDIF){
> +   continue;
> +   }
> +   inst->U.I.Opcode = RC_OPCODE_KIL;
> +   inst->U.I.SrcReg[0] = negate(inst->Prev->U.I.SrcReg[0]);
> +
> +   /* Remove IF */
> +   rc_remove_instruction(inst->Prev);
> +   /* Remove ENDIF */
> +   rc_remove_instruction(inst->Next);
> +   }
> +}
> diff --git a/src/mesa/drivers/dri/r300/compiler/radeon_program_alu.h
> b/src/mesa/drivers/dri/r300/compiler/radeon_program_alu.h
> index 77d..4aa084f 100644
> --- a/src/mesa/drivers/dri/r300/compiler/radeon_program_alu.h
> +++ b/src/mesa/drivers/dri/r300/compiler/radeon_program_alu.h
> @@ -60,4 +60,6 @@ int radeonTransformDeriv(
>struct rc_ins

[Mesa-dev] [Bug 28658] [Gallium/DRI] Occasional Compiz Crashes

2010-07-05 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=28658

Marek Olšák  changed:

   What|Removed |Added

Summary|[r300g] Occasional Compiz   |[Gallium/DRI] Occasional
   |Crashes |Compiz Crashes
  Component|Drivers/DRI/r300|Mesa core
 AssignedTo|dri-de...@lists.freedesktop |mesa-...@lists.freedesktop.
   |.org|org

--- Comment #1 from Marek Olšák  2010-07-05 18:17:18 PDT ---
Changing the component to Mesa core because it's a bug in st/dri.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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