Re: [Mesa-dev] Latest Git broken? error: 'struct gl_array_object' has no member named 'PointSize'

2011-11-29 Thread Theiss, Ingo
Am Dienstag, 29. November 2011 10:27 CET, Chia-I Wu schrieb: > On Tue, Nov 29, 2011 at 5:14 PM, Theiss, Ingo > wrote: > > Dear devs, > > > > is it possible that the current git is broken? After my daily git pull I am > > no longer able to build mesa. > &g

[Mesa-dev] Latest Git broken? error: 'struct gl_array_object' has no member named 'PointSize'

2011-11-29 Thread Theiss, Ingo
Dear devs, is it possible that the current git is broken? After my daily git pull I am no longer able to build mesa. Here is the error which breaks my build: --- gcc -c -o main/ffvertex_prog.o main/ffvertex_prog.c -DFEATURE_GL=1 -DFEATURE_ES1=1 -DFEATURE_ES2=1 -D_GNU_SOURCE -DPTHREADS -DTEXTUR

Re: [Mesa-dev] piglit: regression read-front

2011-11-20 Thread Theiss, Ingo
> Hi there, > > I get a regression in piglit test "read-front -auto" from git-ec174a4 to > git-bdffb94. Can anybody confirm this? I can´t imagine which commit would > have broken this test. > > glxinfo: > > OpenGL renderer string: Gallium 0.4 on AMD BARTS > OpenGL version string: 2.1 Mesa 7.

[Mesa-dev] piglit: regression read-front

2011-11-20 Thread Theiss, Ingo
Hi there, I get a regression in piglit test "read-front -auto" from git-ec174a4 to git-bdffb94. Can anybody confirm this? I can´t imagine which commit would have broken this test. glxinfo: OpenGL renderer string: Gallium 0.4 on AMD BARTS OpenGL version string: 2.1 Mesa 7.12-devel (git-bdffb94)

[Mesa-dev] ir_swizzle @ 0xe134ae0 specifies a channel not present in the value

2011-11-18 Thread Theiss, Ingo
Hi there, while trying to play the game Ryzom with latest mesa compiled from git the program terminates with error "ir_swizzle @ 0xe134ae0 specifies a channel not present in the value". Switching back to the stable branch mesa-7.11 (haven´t tried mesa-7.11.1) the error is gone. My glxinfo:

Re: [Mesa-dev] [PATCH] read_rgba_pixels: Don't force clamping if the renderbuffer is already clamped.

2011-11-17 Thread Theiss, Ingo
Am Mittwoch, 16. November 2011 17:44 CET, Michel Dänzer schrieb: > From: Michel Dänzer > > Signed-off-by: Michel Dänzer > --- > src/mesa/main/readpix.c |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c > ind

[Mesa-dev] ir_dereference_variable @ 0x1195e90 specifies undeclared variable

2011-11-16 Thread Theiss, Ingo
Hi there, running piglit test 'shader_runner tests/spec/glsl-1.10/execution/samplers/in-parameter-struct.shader_test -auto -fbo' the program terminated with signal 6, aborted. glxinfo: OpenGL renderer string: Gallium 0.4 on AMD BARTS OpenGL version string: 2.1 Mesa 7.12-devel (git-010dc29) Ope

Re: [Mesa-dev] piglit: Segmentation fault running fbo-depthstencil -auto readpixels default

2011-11-16 Thread Theiss, Ingo
> > See the second patch I posted (mesa: initialize stencilMap, Stride if > stencilRb==depthRb) > > -Brian > > Hi Brian, the second patch did it. No more segfaults. Great. Thanks! Regards, Ingo ___ mesa-dev mailing list mesa-dev@lists.freedes

Re: [Mesa-dev] piglit: Segmentation fault running fbo-depthstencil -auto readpixels default

2011-11-16 Thread Theiss, Ingo
Am Mittwoch, 16. November 2011 15:58 CET, Brian Paul schrieb: > On 11/16/2011 01:38 AM, Theiss, Ingo wrote: > > Dear devs, > > > > I am getting segmentation faults when running piglit r600.tests with latest > > mesa build from git: > > > > Nov 16 09:2

[Mesa-dev] piglit: Segmentation fault running fbo-depthstencil -auto readpixels default

2011-11-16 Thread Theiss, Ingo
Dear devs, I am getting segmentation faults when running piglit r600.tests with latest mesa build from git: Nov 16 09:21:33 spoc kernel: [74538.198983] radeon :05:00.0: object_init failed for (1431699456, 0x0006) Nov 16 09:21:33 spoc kernel: [74538.198987] [drm:radeon_gem_object_create]

Re: [Mesa-dev] Performance glxSwapBuffers 32 bit vs. 64 bit

2011-11-11 Thread Theiss, Ingo
Am Freitag, 11. November 2011 14:53 CET, Brian Paul schrieb: > 2011/11/11 Michel Dänzer : > > > Anyway, I guess there's room for optimization in glReadPixels... > > Ingo, if you could find out what the format/type parameters to > glReadPixels are, we could look into some optimization in th

Re: [Mesa-dev] Performance glxSwapBuffers 32 bit vs. 64 bit

2011-11-11 Thread Theiss, Ingo
> > > > Ok I have added -mfpmath=sse to the 32-bit CFLAGS and the readback > > performance increased from 30.44 Mpixels/sec to 48.92 Mpixel/sec. We > > are getting closer to the 64-bit performance. > > hmm. you should try -msse2 too. It's implied on 64bits, and I'm not sure if > -march/-mfpmath

Re: [Mesa-dev] Performance glxSwapBuffers 32 bit vs. 64 bit

2011-11-11 Thread Theiss, Ingo
Am Freitag, 11. November 2011 14:33 CET, Michel Dänzer schrieb: > On Fre, 2011-11-11 at 14:15 +0100, Theiss, Ingo wrote: > > Am Freitag, 11. November 2011 12:09 CET, Michel Dänzer > > schrieb: > > > > > So It makes sense to find a glReadPixels

Re: [Mesa-dev] Performance glxSwapBuffers 32 bit vs. 64 bit

2011-11-11 Thread Theiss, Ingo
Am Freitag, 11. November 2011 12:09 CET, Michel Dänzer schrieb: > So It makes sense to find a glReadPixels in VirtualGL's glxSwapBuffers. > > Ah. I thought the time measurements in Ingo's original post were for the > Mesa glXSwapBuffers, not the VirtualGL one. If it's the latter, then > this

Re: [Mesa-dev] Performance glxSwapBuffers 32 bit vs. 64 bit

2011-11-10 Thread Theiss, Ingo
ag, 07. November 2011 16:10 CET, Michel Dänzer schrieb: > On Fre, 2011-11-04 at 13:38 +0100, Theiss, Ingo wrote: > > > > I am using VirtualGL (http://www.virtualgl.org) for full 3D hardware > > accelerated remote OpenGL applications with latest mesa from git > > (compiled for

[Mesa-dev] Performance glxSwapBuffers 32 bit vs. 64 bit

2011-11-04 Thread Theiss, Ingo
Hi everyone, this is my first post to a mailing list here at freedesktop.org and I hope this is the right place for my question/problem. I am using VirtualGL (http://www.virtualgl.org) for full 3D hardware accelerated remote OpenGL applications with latest mesa from git (compiled for both 32 b