mesa3d-dev

Re: [Mesa3d-dev] Current tinderbox regression (dri)

[Dan N. <dbn...@gm...>]

On Tue, Mar 23, 2010 at 11:09 AM, Chris Ball <cj...@la...> wrote:
> Hi,
>
> http://tinderbox.x.org/builds/2010-03-23-0024/logs/libGL/#build
>
> mklib: Making Linux shared library:  mach64_dri.so.tmp
> gcc -o mach64_dri.so.test ../../../../../src/mesa/drivers/dri/common/dri_test.o mach64_dri.so.tmp -L../../../../../lib -lGL
> /usr/bin/ld: cannot find -lGL
> collect2: ld returned 1 exit status
> make[6]: *** [mach64_dri.so] Error 1
>
> (The 12pm GMT build today worked, but the 2pm and later builds fail.)

That's from this commit:

http://cgit.freedesktop.org/mesa/mesa/commit/?id=3e17a5b047124c46ee45dbd1848127c67e0d62f3

This is because we build src/mesa (with the drivers subdir) before we
build the src/glx directory (where libGL is built). This commit should
probably be reverted until it can work better.

--
Dan

[Mesa3d-dev] [Bug 27268] using step function in vec4 constructor is not completely correct

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=27268





--- Comment #1 from Karthik Hariharakrishnan <kar...@ar...>  2010-03-23 11:41:38 PST ---
Created an attachment (id=34372)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=34372)
Output image with step function in vec4 constructor


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] [Bug 27268] New: using step function in vec4 constructor is not completely correct

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=27268

           Summary: using step function in vec4 constructor is not
                    completely correct
           Product: Mesa
           Version: unspecified
          Platform: x86 (IA32)
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Mesa core
        AssignedTo: mes...@li...
        ReportedBy: kar...@ar...


The MESA GL implementation fails OpenGL ES conformance test 
GL/step/step_float_frag_xvary_edgeconsthalf.test.

The generated output doesnt match the expected output generated using
step_float_frag_xvary_edgeconsthalf_ref.frag


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] Current tinderbox regression (dri)

[Chris B. <cj...@la...>]

Hi,

http://tinderbox.x.org/builds/2010-03-23-0024/logs/libGL/#build

mklib: Making Linux shared library:  mach64_dri.so.tmp
gcc -o mach64_dri.so.test ../../../../../src/mesa/drivers/dri/common/dri_test.o mach64_dri.so.tmp -L../../../../../lib -lGL
/usr/bin/ld: cannot find -lGL
collect2: ld returned 1 exit status
make[6]: *** [mach64_dri.so] Error 1

(The 12pm GMT build today worked, but the 2pm and later builds fail.)

- Chris.
-- 
Chris Ball   <cj...@la...>
One Laptop Per Child

[Mesa3d-dev] [Bug 27266] New: Cubosphere: undefined function 'texture2D' / incompatible types in assignment

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=27266

           Summary: Cubosphere: undefined function 'texture2D' /
                    incompatible types in assignment
           Product: Mesa
           Version: git
          Platform: Other
               URL: http://sourceforge.net/projects/cubosphere/
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Mesa core
        AssignedTo: mes...@li...
        ReportedBy: sa...@wh...


Created an attachment (id=34371)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=34371)
distglossbump.frag

When the game Cubosphere is run with shaders turned on, the following errors
occurs:

 Error: problem compiling shader: Error: undefined function 'texture2D' 
 Error: incompatible types in assignment

It seems to happen in the shader distglossbump.frag, which is attached.

I'm not sure if this is a bug in the shader or not, but it seems to run fine in
Windows on ATI hardware.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: [Mesa3d-dev] [PATCH] configure.ac: Bump LIBDRM_RADEON_REQUIRED to 2.4.19

[Marek O. <ma...@gm...>]

On Tue, Mar 23, 2010 at 1:57 PM, Sedat Dilek <sed...@go...>wrote:

> Thanks for the turbo fix, but you workarounded the "real" bug.
>

Frankly, the Mesa build system isn't my area and I don't want to have
anything to do with it.

The square microtiling is now disabled on both older kernels which don't
support it and older libdrm's which don't have the flag defined. No need to
have bleeding-edge stuff of everything is the way to go as long as it
doesn't get messy.

-Marek


> With my patch I get here in build.log:
> ...
> checking for LIBDRM... yes
> ...
> checking for LIBDRM_RADEON... no
> ...
>
> With setting LIBDRM_RADEON_REQUIRED=2.4.19 I expected that the build
> should immediately stop while libdrm package here has version 2.4.18.
> BUT, that is not the case!
>
> Intel_drm has in configure.ac:
> ...
> case $DRI_DIRS in
> *i915*|*i965*)
>    PKG_CHECK_MODULES([INTEL], [libdrm_intel >= 2.4.19])
>    ;;
> esac
> ...
>
> radeon_libdrm on the contrary:
> ...
> case $DRI_DIRS in
> *radeon*|*r200*|*r300*|*r600*)
>    PKG_CHECK_MODULES([LIBDRM_RADEON],
>                      [libdrm_radeon libdrm >= $LIBDRM_RADEON_REQUIRED],
>                      HAVE_LIBDRM_RADEON=yes,
>                      HAVE_LIBDRM_RADEON=no)
>
>    if test "$HAVE_LIBDRM_RADEON" = yes; then
>        RADEON_CFLAGS="-DHAVE_LIBDRM_RADEON=1 $LIBDRM_RADEON_CFLAGS"
>        RADEON_LDFLAGS=$LIBDRM_RADEON_LIBS
>    fi
>    ;;
> esac
> ...
>
> IMO checking for LIBDRM_RADEON_REQUIRED has no real effect, but I am
> not an autotools expert.
> I am not sure if the LIBDRM_RADEON_REQUIRED part could/should be
> handled like in libdrm_intel (...be removed and simplified).
>
> Feedback welcome!
>
> --
> Sedat
>
> On Tue, Mar 23, 2010 at 1:41 PM, Marek Olšák <ma...@gm...> wrote:
> > Fixed in master without requiring new libdrm.
> >
> > -Marek
> >
> > On Tue, Mar 23, 2010 at 1:01 PM, Sedat Dilek <sed...@go...
> >
> > wrote:
> >>
> >> Fixes here latest issues with mesa master GIT [1].
> >>
> >> --
> >> Sedat
> >>
> >> [1] http://marc.info/?l=mesa3d-dev&m=126934502904478&w=2
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Download Intel&#174; Parallel Studio Eval
> >> Try the new software tools for yourself. Speed compiling, find bugs
> >> proactively, and fine-tune applications for parallel performance.
> >> See why Intel Parallel Studio got high marks during beta.
> >> http://p.sf.net/sfu/intel-sw-dev
> >> _______________________________________________
> >> Mesa3d-dev mailing list
> >> Mes...@li...
> >> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> >>
> >
> >
>

[Mesa3d-dev] [Bug 27261] GLSL Compiler fails on the following vertex shader

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=27261


Ian Romanick <id...@fr...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #34360|application/octet-stream    |text/plain
          mime type|                            |




-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: [Mesa3d-dev] [PATCH] st/mesa: make st_manager.c set have[Stencil|Depth]Buffer only if bits > 0

[Luca B. <lu...@lu...>]

OK, pushed.

Re: [Mesa3d-dev] [PATCH] st/mesa: make st_manager.c set have[Stencil|Depth]Buffer only if bits > 0

[Brian P. <br...@vm...>]

Luca Barbieri wrote:
> Fixes a segfault when clearing a non-existent stencil buffer.
> ---
>  src/mesa/state_tracker/st_manager.c |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/src/mesa/state_tracker/st_manager.c b/src/mesa/state_tracker/st_manager.c
> index ca3a29c..cac62e4 100644
> --- a/src/mesa/state_tracker/st_manager.c
> +++ b/src/mesa/state_tracker/st_manager.c
> @@ -333,15 +333,15 @@ st_visual_to_context_mode(const struct st_visual *visual,
>     }
>  
>     if (visual->depth_stencil_format != PIPE_FORMAT_NONE) {
> -      mode->haveDepthBuffer = GL_TRUE;
> -      mode->haveStencilBuffer = GL_TRUE;
> -
>        mode->depthBits =
>           util_format_get_component_bits(visual->depth_stencil_format,
>                 UTIL_FORMAT_COLORSPACE_ZS, 0);
>        mode->stencilBits =
>           util_format_get_component_bits(visual->depth_stencil_format,
>                 UTIL_FORMAT_COLORSPACE_ZS, 1);
> +
> +      mode->haveDepthBuffer = mode->depthBits > 0;
> +      mode->haveStencilBuffer = mode->stencilBits > 0;
>     }
>  
>     if (visual->accum_format != PIPE_FORMAT_NONE) {


Looks good.

-Brian

Re: [Mesa3d-dev] Segfault on glClear of non-existent stencil buffer caused by bd1ce874728c06d08a1f9881f51edbdd2f1c9db0

[Brian P. <br...@vm...>]

Luca Barbieri wrote:
> The problem seems to be in st_manager.c:
>    if (visual->depth_stencil_format != PIPE_FORMAT_NONE) {
>       mode->haveDepthBuffer = GL_TRUE;
>       mode->haveStencilBuffer = GL_TRUE;
> 
>       mode->depthBits =
>          util_format_get_component_bits(visual->depth_stencil_format,
>                UTIL_FORMAT_COLORSPACE_ZS, 0);
>       mode->stencilBits =
>          util_format_get_component_bits(visual->depth_stencil_format,
>                UTIL_FORMAT_COLORSPACE_ZS, 1);
>    }
> 
> This sets haveStencilBuffer even for depth-only buffers.
> 
> How about fixing this to set haveDepthBuffer and haveStencilBuffer
> only if bits > 0, and later removing haveStencilBuffer,
> haveDepthBuffer and haveAccumBuffer in favor of just testing the *bits
> counterparts?

The haveDepth/Stencil fields come from the original SGI GLX.  We 
should probably just test the number of bits in Mesa, as you say. 
Want to make a patch for that?


> BTW, what if we have a floating-point depth buffer, or, say, a shared
> exponent floating-point color buffer? How do we represent that with
> the visual structure?

Those things came along after the SGI GLX release.  They'd have to be 
added to __GLcontextModes.


> Shouldn't we be using the actual formats instead of this *bits stuff,
> maybe by having Mesa look at its internal structures instead of a
> GLXVisual-like struct?

yeah, probably.  I'd have to study it for a while.

-Brian

Re: [Mesa3d-dev] plumbing for gallium swrast_dri.so

[George S. <gsa...@gm...>]

On Sun, Mar 14, 2010 at 12:25 PM, George Sapountzis
<gsa...@gm...> wrote:
> Hi,
>
> I put some patches at
> http://cgit.freedesktop.org/~gsap7/mesa/log/?h=gallium-drisw that do
> the plumbing in order to build the swrast_dri wrapper around gallium
> instead of classic mesa. For reference, swrast_dri is the fallback
> driver loaded by libGL (with LIBGL_ALWAYS_SOFTWARE) and xserver. It
> must not link with libdrm, nor use any drm headers during building
> because it is also used on platforms without drm.
>

I updated the patches with the feedback from the list and added TODO
items at the top of drisw.c with the remaining issues. I think it's in
good state, given the scope of swrastg_dri.so, and would like to merge
this to master. So please review and test, esp. DRI2 and scons (since
I cannot test DRI2 and have a tendency to break the build system ...)

There is also the issue of when to choose swrastg_dri.so over
swrast_dri.so that should be handled by the loaders, just rename
swrastg_dri.so to swrast_dri.so for now.

regards,
George.

[Mesa3d-dev] [PATCH] st/mesa: make st_manager.c set have[Stencil|Depth]Buffer only if bits > 0

[Luca B. <lu...@lu...>]

Fixes a segfault when clearing a non-existent stencil buffer.
---
 src/mesa/state_tracker/st_manager.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/mesa/state_tracker/st_manager.c b/src/mesa/state_tracker/st_manager.c
index ca3a29c..cac62e4 100644
--- a/src/mesa/state_tracker/st_manager.c
+++ b/src/mesa/state_tracker/st_manager.c
@@ -333,15 +333,15 @@ st_visual_to_context_mode(const struct st_visual *visual,
    }
 
    if (visual->depth_stencil_format != PIPE_FORMAT_NONE) {
-      mode->haveDepthBuffer = GL_TRUE;
-      mode->haveStencilBuffer = GL_TRUE;
-
       mode->depthBits =
          util_format_get_component_bits(visual->depth_stencil_format,
                UTIL_FORMAT_COLORSPACE_ZS, 0);
       mode->stencilBits =
          util_format_get_component_bits(visual->depth_stencil_format,
                UTIL_FORMAT_COLORSPACE_ZS, 1);
+
+      mode->haveDepthBuffer = mode->depthBits > 0;
+      mode->haveStencilBuffer = mode->stencilBits > 0;
    }
 
    if (visual->accum_format != PIPE_FORMAT_NONE) {
-- 
1.7.0.1.147.g6d84b

Re: [Mesa3d-dev] Segfault on glClear of non-existent stencil buffer caused by bd1ce874728c06d08a1f9881f51edbdd2f1c9db0

[Luca B. <lu...@lu...>]

The problem seems to be in st_manager.c:
   if (visual->depth_stencil_format != PIPE_FORMAT_NONE) {
      mode->haveDepthBuffer = GL_TRUE;
      mode->haveStencilBuffer = GL_TRUE;

      mode->depthBits =
         util_format_get_component_bits(visual->depth_stencil_format,
               UTIL_FORMAT_COLORSPACE_ZS, 0);
      mode->stencilBits =
         util_format_get_component_bits(visual->depth_stencil_format,
               UTIL_FORMAT_COLORSPACE_ZS, 1);
   }

This sets haveStencilBuffer even for depth-only buffers.

How about fixing this to set haveDepthBuffer and haveStencilBuffer
only if bits > 0, and later removing haveStencilBuffer,
haveDepthBuffer and haveAccumBuffer in favor of just testing the *bits
counterparts?

BTW, what if we have a floating-point depth buffer, or, say, a shared
exponent floating-point color buffer? How do we represent that with
the visual structure?
Shouldn't we be using the actual formats instead of this *bits stuff,
maybe by having Mesa look at its internal structures instead of a
GLXVisual-like struct?

Re: [Mesa3d-dev] Segfault on glClear of non-existent stencil buffer caused by bd1ce874728c06d08a1f9881f51edbdd2f1c9db0

[Luca B. <lu...@lu...>]

We have a visual haveStencilBuffer == 1 but stencilBits == 0 (and no
stencil renderbuffer), which I suppose shouldn't be happening.
visualid and fbconfigid are also 0.

Here is the full structure:
$1 = {next = 0x0, rgbMode = 1 '\001', floatMode = 0 '\000',
colorIndexMode = 0 '\000', doubleBufferMode = 1, stereoMode = 0,
haveAccumBuffer = 0 '\000', haveDepthBuffer = 1 '\001',
  haveStencilBuffer = 1 '\001', redBits = 8, greenBits = 8, blueBits =
8, alphaBits = 8, redMask = 0, greenMask = 0, blueMask = 0, alphaMask
= 0, rgbBits = 32, indexBits = 0, accumRedBits = 0,
  accumGreenBits = 0, accumBlueBits = 0, accumAlphaBits = 0, depthBits
= 24, stencilBits = 0, numAuxBuffers = 0, level = 0, pixmapMode = 0,
visualID = 0, visualType = 0, visualRating = 0, transparentPixel = 0,
  transparentRed = 0, transparentGreen = 0, transparentBlue = 0,
transparentAlpha = 0, transparentIndex = 0, sampleBuffers = 0, samples
= 0, drawableType = 0, renderType = 0, xRenderable = 0, fbconfigID =
0,
  maxPbufferWidth = 0, maxPbufferHeight = 0, maxPbufferPixels = 0,
optimalPbufferWidth = 0, optimalPbufferHeight = 0, visualSelectGroup =
0, swapMethod = 0, screen = 0, bindToTextureRgb = 0,
  bindToTextureRgba = 0, bindToMipmapTexture = 0, bindToTextureTargets
= 0, yInverted = 0}

BTW, what's the purpose of having haveStencilBuffer at all? Isn't
checking stencilBits != 0 enough?

Re: [Mesa3d-dev] Segfault on glClear of non-existent stencil buffer caused by bd1ce874728c06d08a1f9881f51edbdd2f1c9db0

[Brian P. <br...@vm...>]

Luca Barbieri wrote:
> Apparently _mesa_Clear should not set BUFFER_BIT_STENCIL if the visual
> lacks a stencil buffer.
> 
> So it seems the visual is somehow incorrect, or a visual with a
> stencil buffer is being selected but the stencil renderbuffer is not
> actually set.

At line 167 of src/mesa/main/clear.c we check if the user specifies
GL_STENCIL_BUFFER_BIT but the drawing surface has no stencil bits.

So, st_clear() should not be getting BUFFER_BIT_STENCIL if there's no 
stencil buffer.

Perhaps you could debug that a bit further.

-Brian

[Mesa3d-dev] [Bug 27261] GLSL Compiler fails on the following vertex shader

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=27261





--- Comment #7 from Brian Paul <bri...@gm...>  2010-03-23 09:21:42 PST ---
(In reply to comment #6)
> It looks like 7.8rc2 fixes the issue but fails a whole lot of other shaders.
> More specifically lots of tests fail in the GL/build section in OpenGL ES
> Conformance suite.

The GL/build section is notoriously complicated but many/most of the tests in
that section did pass at one time.  There may have been a regression.  I'm
afraid I don't have time to did into it now though.


> Is there a architectural diagram for the different components in Mesa?

There's some diagrams focussing on Gallium but I don't have anything handy for
Mesa.  You can find most things with a little bit of grep'ing.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] [Bug 27265] GLSL Compiler doesnt link the attached vertex shader

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=27265





--- Comment #3 from Brian Paul <bri...@gm...>  2010-03-23 09:19:23 PST ---
Created an attachment (id=34368)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=34368)
do varying var allocation upon usage to use fewer regs

The fragment shader is trying to read a varying var that's never written to (or
declared in) the vertex shader.  So that's an error.

I modified the fragment shader accordingly and found the link still failed
because of too many varying vars.  However, a lot of varying vars are declared
but not actually used in the shader.

The following patch avoids allocating a register slot for varyings that aren't
used.  With this patch, the test works.  Want to give it a try?  I've only
lightly tested it so far.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: [Mesa3d-dev] Segfault on glClear of non-existent stencil buffer caused by bd1ce874728c06d08a1f9881f51edbdd2f1c9db0

[Luca B. <lu...@lu...>]

Apparently _mesa_Clear should not set BUFFER_BIT_STENCIL if the visual
lacks a stencil buffer.

So it seems the visual is somehow incorrect, or a visual with a
stencil buffer is being selected but the stencil renderbuffer is not
actually set.

[Mesa3d-dev] Segfault on glClear of non-existent stencil buffer caused by bd1ce874728c06d08a1f9881f51edbdd2f1c9db0

[Luca B. <lu...@lu...>]

Commit bd1ce874728c06d08a1f9881f51edbdd2f1c9db0 "st/dri: Switch from
st_public.h to st_api.h" broke etracer on Gallium nvfx.

The root cause appears to be that etracer calls glClear with the
stencil bit set, but does not ask for a stencil buffer.
Enabling "stencil_buffer" in the etracer config works around the issue.

This results in strb being null, and the check for strb->surface in
st_clear segfaulting.

I'm not sure why that commit would cause this: I guess it
unintentionally indirectly changes the way st/dri handles stencil
buffers.

Changing if(strb->surface) to if(strb && strb->surface) everywhere
inside st_clear fixes the issue, but I'm not at all sure it is the
right fix.

Should st_clear check strb for null or is it supposed to be always
non-null? (and the bug is thus somewhere else?)
Did that commit just expose a bug, or is it buggy itself?

[Mesa3d-dev] [Bug 27265] GLSL Compiler doesnt link the attached vertex shader

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=27265


Kristof Ralovich <kri...@gm...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #34367|application/octet-stream    |text/x-csrc
          mime type|                            |




-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] [Bug 27265] GLSL Compiler doesnt link the attached vertex shader

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=27265


Kristof Ralovich <kri...@gm...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #34365|application/octet-stream    |text/x-csrc
          mime type|                            |




-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] [Bug 22536] glxgears_pixmap shows black screen and seeing error message from X

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=22536


Yu Dai <yu...@in...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED




-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] [Bug 22536] glxgears_pixmap shows black screen and seeing error message from X

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=22536


Yu Dai <yu...@in...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED




-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: [Mesa3d-dev] [PROPOSAL-V2] configure.ac: Introduce LIBDRM_INTEL_REQUIRED variable and Really check for LIBDRM_RADEON_REQUIRED

[Dan N. <dbn...@gm...>]

On Tue, Mar 23, 2010 at 7:04 AM, Sedat Dilek <sed...@go...> wrote:
> V2 of my proposal.

0001: Reviewed-by: Dan Nicholson <dbn...@gm...>

0002: Having a hard requirement on libdrm_radeon needs to be passed by
the radeon developers. If it is deemed OK, then just drop the 3rd and
4th argument to the PKG_CHECK_MODULES and the HAVE_LIBDRM_RADEON
variable.

--
Dan

[Mesa3d-dev] [Bug 27261] GLSL Compiler fails on the following vertex shader

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=27261





--- Comment #6 from Karthik Hariharakrishnan <kar...@ar...>  2010-03-23 08:04:53 PST ---
(In reply to comment #5)
> (In reply to comment #4)
> 
> > I will try the latest release candidate and see if the problem has been fixed.
> > I have also been observing random failures in the GLES conformance suite when I
> > run with MESA. Has there been some memory leaks etc fixed in the new release?
> 
> I don't know what would cause random failures.
> 
> Every so often I find/fix memory leaks but I don't know if that would be
> related to your issue.
> 

It looks like 7.8rc2 fixes the issue but fails a whole lot of other shaders.
More specifically lots of tests fail in the GL/build section in OpenGL ES
Conformance suite.

Is there a architectural diagram for the different components in Mesa?

Thanks


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.