[Mesa3d-dev] [Bug 25663] Compile Failures on Bluegene/L
http://bugs.freedesktop.org/show_bug.cgi?id=25663 --- Comment #14 from Ben Matthews 2009-12-16 21:17:50 PST --- I think it's safe to assume that .a is always going to be the library extension. Some background which hopefully helps answer the question better: It's important to note that there is no concept of a shared library on BG/L. BG/L systems are actually a rather complex architecture. There are three major user facing parts of a BG/L system. There's one or more fast IBM P series machines which provide the UI and cross compilers for the main compute system. The compilers generate a static binary image with the user application and a minimal operating system called blrts. The user can then give that binary image to the scheduler which loads it into RAM on each compute node using some largely undocumented magic. The compute nodes then interface with the rest of the world through a smaller number of IO nodes. The IO nodes are minimal Linux systems which run a server called CIOD which takes system calls on from the compute nodes (over one of the internal interconnects) and acts on them (over GigE.. NFS, Sockets, etc). Blrts is intended to look like Linux to the developer but have a lot less jitter. Unfortunately there are a bunch of features that were never implemented (presumably because they'd be hard to fit into this architecture), including shared libraries/dlopen, threads and listen(). If you want to support all Bluegene systems there are a couple places where this can break down. There are two other classes of Bluegene hardware: the /P and the /Q. BG/Q isn't publicly available yet, but BG/P is and may do things differently. I know it supports more of the features that are missing in /L, but I don't know too much more at the moment. I'm in the process of getting an account on a BG/P system to test the code I'm trying to port so if it's of interest to mesa I can probably tell you more in a few days/weeks. The second possible problem is that there's an unofficial alternative to blrts and a corresponding IO node image called ZeptoOS. ZeptoOS runs on both BG/L and BG/P hardware and provides more features than IBM's stack (as well as another toolchain). I'll try building with autoconf tomorrow. Thus far I've been using the old build system because it saves me having to trick autoconf into cross compiling (sometimes that's not too bad and sometimes it's a huge problem depending on what tests it wants to do). -- 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 Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 25663] Compile Failures on Bluegene/L
http://bugs.freedesktop.org/show_bug.cgi?id=25663 --- Comment #13 from Tom Fogal 2009-12-16 20:05:46 PST --- Created an attachment (id=32137) --> (http://bugs.freedesktop.org/attachment.cgi?id=32137) Fix LIB_EXTENSION in configure.ac This should address the issue noted in comment #2, at least when using the autoconf build. Make sure you `autoreconf' after applying. Ben, can you expound on the host string? Are all "*-bgl-*" systems going to use '.a' as the library extension? I guess I'm just not clear on what the "blrts" means, so I've pretended it's important in this patch. -- 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 Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 25663] Compile Failures on Bluegene/L
http://bugs.freedesktop.org/show_bug.cgi?id=25663 --- Comment #12 from Tom Fogal 2009-12-16 16:29:43 PST --- Created an attachment (id=32135) --> (http://bugs.freedesktop.org/attachment.cgi?id=32135) Patch to use the fallback code in more cases It appears patches get eaten when using the email interface. -- 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 Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] swrast: _ae_invalidate_state segfault executing a VBO
tom fogal writes: > A user of ours is hitting a segfault in our application, which ships > Mesa-7.5 currently. > > The stack trace is attached. It looks to me like Qt is invoking > the system's libGL, which loads a DRI driver, and then somehow that > DRI driver ends up calling routines in our private libOSMesa. The > libOSMesa that gets built is mangled, should that matter. It appears > as if the user is running Fedora 11. Update -- the user reports that everything works fine when LIBGL_ALWAYS_INDIRECT is set in their environment. -tom -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] swrast: _ae_invalidate_state segfault executing a VBO
A user of ours is hitting a segfault in our application, which ships Mesa-7.5 currently. The stack trace is attached. It looks to me like Qt is invoking the system's libGL, which loads a DRI driver, and then somehow that DRI driver ends up calling routines in our private libOSMesa. The libOSMesa that gets built is mangled, should that matter. It appears as if the user is running Fedora 11. I looked in _ae_invalidate_state, and the only opportunity I see for a segfault is dereferencing a context pointer. It seems like this is internal state though, and further this happens *while* initializing a context, so that seems suspect. That said, it seems rather strange that a DRI driver is jumping into our private mangled-OSMesa to initialize a context. Are we getting bit by a flat namespace here? It appears libOSMesa is exporting many vbo_ functions, but AFAICT these should be internal symbols: $ nm -AC libOSMesa.so | grep vbo_ ... libOSMesa.so:000f35df T vbo_exec_vtx_destroy libOSMesa.so:000f6aae T vbo_exec_vtx_flush libOSMesa.so:000f3472 T vbo_exec_vtx_init I'll note that some vbo_ functions do seem to be internal. Side note -- how does an `AEcontext' differ from, say, a `GLcontext', or, conceptually, from a glX context? -tom Traceback (most recent call last): File "", line 27, in ImportError: No module named os.path [?1034h[Thread debugging using libthread_db enabled] Traceback (most recent call last): File "/usr/share/gdb/auto-load/usr/lib/libstdc++.so.6.0.12-gdb.py", line 26, in from libstdcxx.v6.printers import register_libstdcxx_printers File "/usr/lib/python2.6/site-packages/gdb/libstdcxx/v6/printers.py", line 19, in import itertools ImportError: No module named itertools [New Thread 0xb7c0cb70 (LWP 30038)] [Thread 0xb7c0cb70 (LWP 30038) exited] [New Thread 0xb720bb70 (LWP 30054)] [Thread 0xb720bb70 (LWP 30054) exited] Program received signal SIGSEGV, Segmentation fault. 0x01ddbfa3 in _ae_invalidate_state () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libOSMesa.so.7 #0 0x01ddbfa3 in _ae_invalidate_state () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libOSMesa.so.7 No symbol table info available. #1 0x01d3ee95 in vbo_exec_invalidate_state () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libOSMesa.so.7 No symbol table info available. #2 0x01d3edd9 in vbo_exec_init () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libOSMesa.so.7 No symbol table info available. #3 0x01d3ec0e in _vbo_CreateContext () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libOSMesa.so.7 No symbol table info available. #4 0x01b1e467 in ?? () from /usr/lib/dri/swrast_dri.so No symbol table info available. #5 0x0671df90 in ?? () from /usr/lib/libGL.so.1 No symbol table info available. #6 0x06701740 in ?? () from /usr/lib/libGL.so.1 No symbol table info available. #7 0x06701a43 in glXCreateContext () from /usr/lib/libGL.so.1 No symbol table info available. #8 0x004ec1dc in QGLContext::chooseContext(QGLContext const*) () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libQtOpenGL.so.4 No symbol table info available. #9 0x004bbb4a in QGLContext::create(QGLContext const*) () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libQtOpenGL.so.4 No symbol table info available. #10 0x004ea6fc in QGLWidget::setContext(QGLContext*, QGLContext const*, bool) () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libQtOpenGL.so.4 No symbol table info available. #11 0x004b6adf in ?? () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libQtOpenGL.so.4 No symbol table info available. #12 0x004eb916 in ?? () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libQtOpenGL.so.4 No symbol table info available. #13 0x004b8368 in QGLWidget::QGLWidget(QWidget*, QGLWidget const*, QFlags) () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libQtOpenGL.so.4 No symbol table info available. #14 0x004edd00 in ?? () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libQtOpenGL.so.4 No symbol table info available. #15 0x004b6a85 in ?? () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libQtOpenGL.so.4 No symbol table info available. #16 0x004eb916 in ?? () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libQtOpenGL.so.4 No symbol table info available. #17 0x004b8508 in QGLWidget::QGLWidget(QWidget*, QGLWidget const*, QFlags) () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libQtOpenGL.so.4 No symbol table info available. #18 0x0040774f in vtkQtGLWidget::vtkQtGLWidget(QWidget*) () from /home/research/alexanda/projects/visit.trunk/src/exe/../lib/libvtkqt.so No symbol table info available. #19 0x004094cc in vtkQtRenderWindow::vtkQtRenderWindow(QWidget*, QFlags) () from /home/rese
[Mesa3d-dev] [Bug 25663] Compile Failures on Bluegene/L
http://bugs.freedesktop.org/show_bug.cgi?id=25663 --- Comment #11 from Tom Fogal 2009-12-16 16:02:49 PST --- bugzilla-dae...@freedesktop.org writes: > --- Comment #10 from Ben Matthews 2009-12-16 09:42:25 PST > The gcc build is still tripping up on sys/endian.h not being found (I have no > idea why): > > /bgl/BlueLight/ppcfloor/blrts-gnu/bin/powerpc-bgl-blrts-gnu-gcc -c > -I../../include -I../../src/mesa -I../../src/gallium/include > -I../../src/gallium/auxiliary -O3 -ansi -pedantic -fPIC -ffast-math > -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE > -fno-strict-aliasing main/accum.c -o main/accum.o > /bgl/BlueLight/ppcfloor/blrts-gnu/bin/powerpc-bgl-blrts-gnu-gcc -c > -I../../include -I../../src/mesa -I../../src/gallium/include > -I../../src/gallium/auxiliary -O3 -ansi -pedantic -fPIC -ffast-math > -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE > -fno-strict-aliasing main/attrib.c -o main/attrib.o > /bgl/BlueLight/ppcfloor/blrts-gnu/bin/powerpc-bgl-blrts-gnu-gcc -c > -I../../include -I../../src/mesa -I../../src/gallium/include > -I../../src/gallium/auxiliary -O3 -ansi -pedantic -fPIC -ffast-math > -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE > -fno-strict-aliasing main/arrayobj.c -o main/arrayobj.o > In file included from main/imports.h:39, > from main/arrayobj.c:44: > main/compiler.h:244:24: sys/endian.h: No such file or directory Hrm. The ifdef magic in compiler.h is: #if __linux__ use byteswap.h's endian-swapping routine #elif __APPLE__ use CFByteOrder's routine #elif _AIX or bluegene do the swap manually in C #else use sys/endian.h's routine. #endif I guess it would be more robust if we used something like the attached patch implements (warning, tested only on Linux ;). > That said, if I manually feed this code to the same gcc that mesa is using I > get the expected results: > > cat test.c > #if defined(__blrts__) > #error __blrts__ > #endif > #if (defined(__blrts) && !defined(blah) && !defined(_GNU_SOURCE)) > #error defined > #else > #if defined(_GNU_SOURCE) > #warning _GNU_SOURCE > #endif > #endif > #ifdef __blrts > #error __blrts > #endif > > /bgl/BlueLight/ppcfloor/blrts-gnu/bin/powerpc-bgl-blrts-gnu-gcc test.c > test.c:2:2: #error __blrts__ > test.c:8:2: warning: #warning _GNU_SOURCE > test.c:12:2: #error __blrts Mesa adds a lot of defines, e.g. POSIX_C_SOURCE, which probably have an effect on which system includes get brought in implicitly, and which defines are added implicitly. -tom -- 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 Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Piglit patch
On Sat, 12 Dec 2009 01:27:52 +0100, Maciej Cencora wrote: > Dnia sobota, 21 listopada 2009 o 20:41:34 Maciej Cencora napisał(a): > > Hi, > > > > attached patch fixes texturing/s3tc-texsubimage test. It passes now on > > software rasterizer. R300 needs ~2% tolerance to pass. > > > > Regards, > > Maciej Cencora > > > > Any reason this patch hasn't been applied yet? > > Cheers, > Maciej I tried it, and the software rastrization looked obviously wrong but was passing, so I shoved it into a branch and forgot about it. Does it look correct to you on r300? the test should probably be changed to check the whole drawing, not just one pixel from each quadrant of the texture. pgp6UDwsRu0YW.pgp Description: PGP signature -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [gallium] what is wrong when i need FLUSH_CURRENT in st_teximage_flush_before_map()
With the help of scons i actually managed to build a softpipe and came
to the conclusion this is working fine too. This is really odd.
Maarten.
On Wed, Dec 16, 2009 at 8:01 PM, Maarten Maathuis wrote:
> did a realclean and got softpipe to build, but it still doesn't work.
>
> warzone2100: swrast/s_span.c:1477: _swrast_write_rgba_span: Assertion
> `rb->_BaseFormat == 0x1908 || rb->_BaseFormat == 0x1907' failed.
>
> On Wed, Dec 16, 2009 at 7:20 PM, Maarten Maathuis
> wrote:
>> On Sat, Dec 12, 2009 at 11:21 PM, Maarten Maathuis
>> wrote:
>>> On Sat, Dec 12, 2009 at 8:03 PM, Keith Whitwell wrote:
Maarten,
Interesting. There are reasons this might be happening indeed, but first
can I ask a couple of silly questions...
- Is your bug only on one particular gallium driver, or does eg. softpipe
show the same symptoms?
- What about non-gallium drivers? eg. Mesa swrast?
>>>
>>> That's not silly at all. I could not get softpipe to work (glxinfo:
>>> symbol lookup error: /ts/git/mesa-softpipe/lib/libGL.so.1: undefined
>>> symbol: glAreTexturesResidentEXT), i did get swrast to work. And this
>>> didn't have the problem.
>>>
Keith
From: Maarten Maathuis [madman2...@gmail.com]
Sent: Friday, December 11, 2009 4:41 PM
To: Keith Whitwell
Cc: mesa3d-dev@lists.sourceforge.net
Subject: Re: [Mesa3d-dev] [gallium] what is wrong when i need
FLUSH_CURRENT in st_teximage_flush_before_map()
On Tue, Dec 8, 2009 at 7:21 PM, Maarten Maathuis
wrote:
> It was TexSubImage, and i added FLUSH_CURRENT after
> ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH and it seems to fix the issue. The
> difference between the two is that one triggers on NeedFlush &
> FLUSH_UPDATE_CURRENT and the other on NeedFlush &
> FLUSH_STORED_VERTICES. Any idea what the problem is?
>
> Maarten.
>
> On Tue, Dec 8, 2009 at 3:36 PM, Keith Whitwell wrote:
>> On Fri, 2009-12-04 at 13:51 -0800, Maarten Maathuis wrote:
>>> I recently noticed a regression in the nv50 gallium driver, with a few
>>> hours of bisecting i figured out i need FLUSH_CURRENT called
>>> unconditionally in st_teximage_flush_before_map(). Otherwise in
>>> warzone2100 several small textures (glyphs) go missing. Does this make
>>> any sense or perhaps provide a hint as to the real problem. One other
>>> person has tried and could not reproduce this issue. I've tried doing
>>> a 100 msec wait instead and gpu flush (FLUSH_FRAME to be precise) +
>>> 100 msec wait. Neither work, which leads me to believe something is
>>> still stuck in the state tracker.
>>
>> Maarten,
>>
>> FLUSH_CURRENT really just flushes internal Mesa state, rather than doing
>> anything to the GPU or driver. In particular it will:
>>
>> - Make sure the VBO module issues any pending draw commands
>> - Asks the VBO module to update ctx->Current.Attrib[]
>> - Similarly for ctx->Light.MatAttrib[]
>> - And provokes the unmapping of the in-progress immediate VBO.
>>
>> Most of this is also done by ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH(), which
>> is being called at the top of _mesa_TexImage2D().
>>
>> So it's a surprise that calling FLUSH_CURRENT has any effect, as it
>> really just updates a few mesa internal values once ASSERT_OUTSIDE...()
>> has been called.
>>
>> What would happen if you lifted your FLUSH_CURRENT up into the highest
>> mesa function on the callstack?
>>
>> Keith
>>
>>
>
This is the smallest change i could find that would work.
diff --git a/src/mesa/vbo/vbo_exec_api.c b/src/mesa/vbo/vbo_exec_api.c
index f0a7eea..f45761e 100644
--- a/src/mesa/vbo/vbo_exec_api.c
+++ b/src/mesa/vbo/vbo_exec_api.c
@@ -370,6 +370,8 @@ do {
\
if (N>3) dest[3] = V3; \
} \
\
+ exec->ctx->Driver.NeedFlush |= FLUSH_STORED_VERTICES; \
+ \
if ((A) == 0) { \
GLuint i; \
\
@@ -377,7 +379,6 @@ do {
\
exec->vtx.buffer_ptr[i] = exec->vtx.vertex[i]; \
\
exec->vtx.buffer_ptr += exec->vtx.vertex_size; \
- exec->ctx->Driver.NeedFlush |= FLUSH_STORED_VERTICES; \
Re: [Mesa3d-dev] [gallium] what is wrong when i need FLUSH_CURRENT in st_teximage_flush_before_map()
did a realclean and got softpipe to build, but it still doesn't work.
warzone2100: swrast/s_span.c:1477: _swrast_write_rgba_span: Assertion
`rb->_BaseFormat == 0x1908 || rb->_BaseFormat == 0x1907' failed.
On Wed, Dec 16, 2009 at 7:20 PM, Maarten Maathuis wrote:
> On Sat, Dec 12, 2009 at 11:21 PM, Maarten Maathuis
> wrote:
>> On Sat, Dec 12, 2009 at 8:03 PM, Keith Whitwell wrote:
>>> Maarten,
>>>
>>> Interesting. There are reasons this might be happening indeed, but first
>>> can I ask a couple of silly questions...
>>>
>>> - Is your bug only on one particular gallium driver, or does eg. softpipe
>>> show the same symptoms?
>>> - What about non-gallium drivers? eg. Mesa swrast?
>>
>> That's not silly at all. I could not get softpipe to work (glxinfo:
>> symbol lookup error: /ts/git/mesa-softpipe/lib/libGL.so.1: undefined
>> symbol: glAreTexturesResidentEXT), i did get swrast to work. And this
>> didn't have the problem.
>>
>>>
>>> Keith
>>>
>>> From: Maarten Maathuis [madman2...@gmail.com]
>>> Sent: Friday, December 11, 2009 4:41 PM
>>> To: Keith Whitwell
>>> Cc: mesa3d-dev@lists.sourceforge.net
>>> Subject: Re: [Mesa3d-dev] [gallium] what is wrong when i need FLUSH_CURRENT
>>> in st_teximage_flush_before_map()
>>>
>>> On Tue, Dec 8, 2009 at 7:21 PM, Maarten Maathuis
>>> wrote:
It was TexSubImage, and i added FLUSH_CURRENT after
ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH and it seems to fix the issue. The
difference between the two is that one triggers on NeedFlush &
FLUSH_UPDATE_CURRENT and the other on NeedFlush &
FLUSH_STORED_VERTICES. Any idea what the problem is?
Maarten.
On Tue, Dec 8, 2009 at 3:36 PM, Keith Whitwell wrote:
> On Fri, 2009-12-04 at 13:51 -0800, Maarten Maathuis wrote:
>> I recently noticed a regression in the nv50 gallium driver, with a few
>> hours of bisecting i figured out i need FLUSH_CURRENT called
>> unconditionally in st_teximage_flush_before_map(). Otherwise in
>> warzone2100 several small textures (glyphs) go missing. Does this make
>> any sense or perhaps provide a hint as to the real problem. One other
>> person has tried and could not reproduce this issue. I've tried doing
>> a 100 msec wait instead and gpu flush (FLUSH_FRAME to be precise) +
>> 100 msec wait. Neither work, which leads me to believe something is
>> still stuck in the state tracker.
>
> Maarten,
>
> FLUSH_CURRENT really just flushes internal Mesa state, rather than doing
> anything to the GPU or driver. In particular it will:
>
> - Make sure the VBO module issues any pending draw commands
> - Asks the VBO module to update ctx->Current.Attrib[]
> - Similarly for ctx->Light.MatAttrib[]
> - And provokes the unmapping of the in-progress immediate VBO.
>
> Most of this is also done by ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH(), which
> is being called at the top of _mesa_TexImage2D().
>
> So it's a surprise that calling FLUSH_CURRENT has any effect, as it
> really just updates a few mesa internal values once ASSERT_OUTSIDE...()
> has been called.
>
> What would happen if you lifted your FLUSH_CURRENT up into the highest
> mesa function on the callstack?
>
> Keith
>
>
>>>
>>> This is the smallest change i could find that would work.
>>>
>>> diff --git a/src/mesa/vbo/vbo_exec_api.c b/src/mesa/vbo/vbo_exec_api.c
>>> index f0a7eea..f45761e 100644
>>> --- a/src/mesa/vbo/vbo_exec_api.c
>>> +++ b/src/mesa/vbo/vbo_exec_api.c
>>> @@ -370,6 +370,8 @@ do {
>>> \
>>> if (N>3) dest[3] = V3; \
>>> } \
>>> \
>>> + exec->ctx->Driver.NeedFlush |= FLUSH_STORED_VERTICES; \
>>> + \
>>> if ((A) == 0) { \
>>> GLuint i; \
>>> \
>>> @@ -377,7 +379,6 @@ do {
>>> \
>>> exec->vtx.buffer_ptr[i] = exec->vtx.vertex[i]; \
>>> \
>>> exec->vtx.buffer_ptr += exec->vtx.vertex_size; \
>>> - exec->ctx->Driver.NeedFlush |= FLUSH_STORED_VERTICES; \
>>> \
>>> if (++exec->vtx.vert_count >= exec->vtx.max_vert) \
>>> vbo_exec_vtx_wrap( exec ); \
>>>
>>
>
> Any ideas? This time mesa with only softpipe doesn't even build (what
> do you use to build softpipe?):
>
> gcc -I../../in
Re: [Mesa3d-dev] Mesa (master): r300g: flush CS if a buffer being deleted is referenced by it
2009/12/16 Michel Dänzer :
> On Tue, 2009-12-15 at 19:04 -0800, Corbin Simpson wrote:
>> Module: Mesa
>> Branch: master
>> Commit: 417ce06306962a9355cbb35cefcdea1951b0ce85
>> URL:
>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=417ce06306962a9355cbb35cefcdea1951b0ce85
>>
>> Author: Marek Olšák
>> Date: Sat Dec 12 23:44:02 2009 +0100
>>
>> r300g: flush CS if a buffer being deleted is referenced by it
>
> [...]
>
>> diff --git a/src/gallium/winsys/drm/radeon/core/radeon_buffer.c
>> b/src/gallium/winsys/drm/radeon/core/radeon_buffer.c
>> index 2a8daed..76acc99 100644
>> --- a/src/gallium/winsys/drm/radeon/core/radeon_buffer.c
>> +++ b/src/gallium/winsys/drm/radeon/core/radeon_buffer.c
>> @@ -131,6 +132,11 @@ static void radeon_buffer_del(struct pipe_buffer
>> *buffer)
>> {
>> struct radeon_pipe_buffer *radeon_buffer =
>> (struct radeon_pipe_buffer*)buffer;
>> + struct radeon_winsys_priv *priv = radeon_buffer->ws->priv;
>> +
>> + if (radeon_bo_is_referenced_by_cs(radeon_buffer->bo, priv->cs)) {
>> + priv->cs->space_flush_fn(priv->cs->space_flush_data);
>> + }
>
> Why would this be necessary?
>
>
> --
> Earthling Michel Dänzer | http://www.vmware.com
> Libre software enthusiast | Debian, X and DRI developer
>
Oh, it doesn't seem to be needed at all. Feel free to revert this commit.
Marek
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [gallium] what is wrong when i need FLUSH_CURRENT in st_teximage_flush_before_map()
On Sat, Dec 12, 2009 at 11:21 PM, Maarten Maathuis wrote:
> On Sat, Dec 12, 2009 at 8:03 PM, Keith Whitwell wrote:
>> Maarten,
>>
>> Interesting. There are reasons this might be happening indeed, but first
>> can I ask a couple of silly questions...
>>
>> - Is your bug only on one particular gallium driver, or does eg. softpipe
>> show the same symptoms?
>> - What about non-gallium drivers? eg. Mesa swrast?
>
> That's not silly at all. I could not get softpipe to work (glxinfo:
> symbol lookup error: /ts/git/mesa-softpipe/lib/libGL.so.1: undefined
> symbol: glAreTexturesResidentEXT), i did get swrast to work. And this
> didn't have the problem.
>
>>
>> Keith
>>
>> From: Maarten Maathuis [madman2...@gmail.com]
>> Sent: Friday, December 11, 2009 4:41 PM
>> To: Keith Whitwell
>> Cc: mesa3d-dev@lists.sourceforge.net
>> Subject: Re: [Mesa3d-dev] [gallium] what is wrong when i need FLUSH_CURRENT
>> in st_teximage_flush_before_map()
>>
>> On Tue, Dec 8, 2009 at 7:21 PM, Maarten Maathuis
>> wrote:
>>> It was TexSubImage, and i added FLUSH_CURRENT after
>>> ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH and it seems to fix the issue. The
>>> difference between the two is that one triggers on NeedFlush &
>>> FLUSH_UPDATE_CURRENT and the other on NeedFlush &
>>> FLUSH_STORED_VERTICES. Any idea what the problem is?
>>>
>>> Maarten.
>>>
>>> On Tue, Dec 8, 2009 at 3:36 PM, Keith Whitwell wrote:
On Fri, 2009-12-04 at 13:51 -0800, Maarten Maathuis wrote:
> I recently noticed a regression in the nv50 gallium driver, with a few
> hours of bisecting i figured out i need FLUSH_CURRENT called
> unconditionally in st_teximage_flush_before_map(). Otherwise in
> warzone2100 several small textures (glyphs) go missing. Does this make
> any sense or perhaps provide a hint as to the real problem. One other
> person has tried and could not reproduce this issue. I've tried doing
> a 100 msec wait instead and gpu flush (FLUSH_FRAME to be precise) +
> 100 msec wait. Neither work, which leads me to believe something is
> still stuck in the state tracker.
Maarten,
FLUSH_CURRENT really just flushes internal Mesa state, rather than doing
anything to the GPU or driver. In particular it will:
- Make sure the VBO module issues any pending draw commands
- Asks the VBO module to update ctx->Current.Attrib[]
- Similarly for ctx->Light.MatAttrib[]
- And provokes the unmapping of the in-progress immediate VBO.
Most of this is also done by ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH(), which
is being called at the top of _mesa_TexImage2D().
So it's a surprise that calling FLUSH_CURRENT has any effect, as it
really just updates a few mesa internal values once ASSERT_OUTSIDE...()
has been called.
What would happen if you lifted your FLUSH_CURRENT up into the highest
mesa function on the callstack?
Keith
>>>
>>
>> This is the smallest change i could find that would work.
>>
>> diff --git a/src/mesa/vbo/vbo_exec_api.c b/src/mesa/vbo/vbo_exec_api.c
>> index f0a7eea..f45761e 100644
>> --- a/src/mesa/vbo/vbo_exec_api.c
>> +++ b/src/mesa/vbo/vbo_exec_api.c
>> @@ -370,6 +370,8 @@ do {
>> \
>> if (N>3) dest[3] = V3; \
>> } \
>> \
>> + exec->ctx->Driver.NeedFlush |= FLUSH_STORED_VERTICES; \
>> + \
>> if ((A) == 0) { \
>> GLuint i; \
>> \
>> @@ -377,7 +379,6 @@ do {
>> \
>> exec->vtx.buffer_ptr[i] = exec->vtx.vertex[i]; \
>> \
>> exec->vtx.buffer_ptr += exec->vtx.vertex_size; \
>> - exec->ctx->Driver.NeedFlush |= FLUSH_STORED_VERTICES; \
>> \
>> if (++exec->vtx.vert_count >= exec->vtx.max_vert) \
>> vbo_exec_vtx_wrap( exec ); \
>>
>
Any ideas? This time mesa with only softpipe doesn't even build (what
do you use to build softpipe?):
gcc -I../../include -g -O2 -Wall -Wmissing-prototypes -std=c99
-ffast-math -fno-strict-aliasing -g -fPIC -D_GNU_SOURCE -DPTHREADS
-DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XSHM arbfplight.c readtex.o
-L../../lib -lglut -lGLEW -lGLU -lGL -lm -o arbfplight
../../lib/libGL.so: undefined reference to `gl_dispatch_stub_361'
../../lib/libGL.so: undefined reference to `gl_dispatch_stub_356'
../..
[Mesa3d-dev] [Bug 25663] Compile Failures on Bluegene/L
http://bugs.freedesktop.org/show_bug.cgi?id=25663 --- Comment #10 from Ben Matthews 2009-12-16 09:42:25 PST --- The gcc build is still tripping up on sys/endian.h not being found (I have no idea why): /bgl/BlueLight/ppcfloor/blrts-gnu/bin/powerpc-bgl-blrts-gnu-gcc -c -I../../include -I../../src/mesa -I../../src/gallium/include -I../../src/gallium/auxiliary -O3 -ansi -pedantic -fPIC -ffast-math -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -fno-strict-aliasing main/accum.c -o main/accum.o /bgl/BlueLight/ppcfloor/blrts-gnu/bin/powerpc-bgl-blrts-gnu-gcc -c -I../../include -I../../src/mesa -I../../src/gallium/include -I../../src/gallium/auxiliary -O3 -ansi -pedantic -fPIC -ffast-math -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -fno-strict-aliasing main/attrib.c -o main/attrib.o /bgl/BlueLight/ppcfloor/blrts-gnu/bin/powerpc-bgl-blrts-gnu-gcc -c -I../../include -I../../src/mesa -I../../src/gallium/include -I../../src/gallium/auxiliary -O3 -ansi -pedantic -fPIC -ffast-math -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -fno-strict-aliasing main/arrayobj.c -o main/arrayobj.o In file included from main/imports.h:39, from main/arrayobj.c:44: main/compiler.h:244:24: sys/endian.h: No such file or directory In file included from main/imports.h:39In file included from main/mtypes.h:39In file included from main/mtypes.h:39, from main/accum.h:41, from main/accum.h:41, from main/api_exec.c:34, from main/accum.c:26In file included from main/mtypes.h:39: , from main/api_noop.h:28../../src/mesa/main/compiler.h:244:24:In file included from main/mtypes.h:39, from main/api_noop.c:27In file included from main/mtypes.h:39: , from main/api_validate.h:31In file included from main/imports.h:39 : sys/endian.h: No such file or directory../../src/mesa/main/compiler.h:244:24:, from main/api_arrayelt.h:30../../src/mesa/main/compiler.h:244:24:, from main/api_arrayelt.c:30, from main/api_validate.c:26, from main/macros.h:34 , from main/api_loopback.c:33 : sys/endian.h: No such file or directorymain/compiler.h:244:24: : sys/endian.h: No such file or directory ../../src/mesa/main/compiler.h:244:24: : sys/endian.h: No such file or directory../../src/mesa/main/compiler.h:244:24: sys/endian.h: No such file or directory sys/endian.h: No such file or directory , from main/attrib.c:27: main/compiler.h:244:24: sys/endian.h: No such file or directory In file included from ../../src/mesa/glapi/glapi.h:51, from main/mtypes.h:41, from main/api_noop.h:28, from main/api_noop.c:27: ../../src/mesa/glapi/glthread.h:144:6: '#' is not followed by a macro parameter In file included from ../../src/mesa/glapi/glapi.h:51In file included from ../../src/mesa/glapi/glapi.h:51In file included from ../../src/mesa/glapi/glapi.h:51, from main/mtypes.h:41, from main/mtypes.h:41, from main/mtypes.h:41, from main/accum.h:41, from main/accum.h:41, from main/api_exec.c:34, from main/accum.c:26: , from main/api_arrayelt.h:30: , from main/api_arrayelt.c:30: ../../src/mesa/glapi/glthread.h:144:6:../../src/mesa/glapi/glthread.h:144:6: ../../src/mesa/glapi/glthread.h:144:6: '#' is not followed by a macro parameter '#' is not followed by a macro parameter '#' is not followed by a macro parameter In file included from ../../src/mesa/glapi/glapi.h:51, from main/mtypes.h:41, from main/api_validate.h:31, from main/api_validate.c:26: ../../src/mesa/glapi/glthread.h:144:6: '#' is not followed by a macro parameter In file included from ../../src/mesa/glapi/glapi.h:51, from main/mtypes.h:41, from main/context.h:53, from main/arrayobj.c:45: In file included from ../../src/mesa/glapi/glapi.h:51../../src/mesa/glapi/glthread.h:144:6:, from main/mtypes.h:41, from main/accum.h:41, from main/attrib.c:28: ../../src/mesa/glapi/glthread.h:144:6: '#' is not followed by a macro parameter '#' is not followed by a macro parameter In file included from ../../src/mesa/glapi/glapi.h:51, from main/mtypes.h:41, from main/api_loopback.c:35: ../../src/mesa/glapi/glthread.h:144:6: '#' is not followed by a macro parameter In file included from main/api_arrayelt.h:30, from main/api_arrayelt.c:30: main/mtypes.h:3129: warning: comma at end of enumerator listIn file included from main/api_noop.h:28, from main/api_noop.c:27: main/mtypes.h:3129: warning: comma at end of enumerato
[Mesa3d-dev] [Bug 25663] Compile Failures on Bluegene/L
http://bugs.freedesktop.org/show_bug.cgi?id=25663 --- Comment #9 from Brian Paul 2009-12-16 09:40:23 PST --- OK, I added the missing semicolon. -- 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 Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Mesa 7.6.1 release candidate 4 and Mesa 7.7 release candidate 3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mesa 7.6.1-rc4 available for testing at ftp://freedesktop.org/pub/mesa/7.6.1/ md5sums: d60e0c47066156b6931bd80fdca9b9d5 MesaDemos-7.6.1-rc4.tar.bz2 bc4317e74df749e0c6cc252dfcf6e347 MesaDemos-7.6.1-rc4.tar.gz db2ba74136fa01aecbf79426fb4790a0 MesaDemos-7.6.1-rc4.zip 1c880e63122dfbdc57231cf870fc95cc MesaGLUT-7.6.1-rc4.tar.bz2 a401c49eb6338b2a61d415337eb7b34f MesaGLUT-7.6.1-rc4.tar.gz f039c765320076eaa1d10f467dc7b57c MesaGLUT-7.6.1-rc4.zip 62c063310f870abce39e9fdded8d8b03 MesaLib-7.6.1-rc4.tar.bz2 f334d2df1b2bddc1f3ef5aff9922d808 MesaLib-7.6.1-rc4.tar.gz bc7d2c2bf025723f5c47514e59fb1bf7 MesaLib-7.6.1-rc4.zip Mesa 7.7-rc3 available for testing at ftp://freedesktop.org/pub/mesa/7.7/ md5sums: 2404747b148e05ca74ffb243b6e26606 MesaDemos-7.7-rc3.tar.bz2 e066fce347a537fa5e333b6023dd5ab6 MesaDemos-7.7-rc3.tar.gz 69c0a5200bf46a4c9858bc277832ed01 MesaDemos-7.7-rc3.zip c33e022ba66f759eae6ba1489aa76e59 MesaGLUT-7.7-rc3.tar.bz2 944266e880ecceed06190ea7ae2fce09 MesaGLUT-7.7-rc3.tar.gz 411c103fd10eb4aa0e62055d66a3aa4f MesaGLUT-7.7-rc3.zip 775c278a211deacd722ed599e706a20e MesaLib-7.7-rc3.tar.bz2 dfbb7e1ee88b49e3a61025d5e7c2ccb2 MesaLib-7.7-rc3.tar.gz 6a53619873b0ee026a74bfcab51769be MesaLib-7.7-rc3.zip These should be a the final release candidates. My hope is that next Monday (12/21) both Mesa 7.6.1 and Mesa 7.7 "final" will be released. I also hope that there won't be many changes to the code between now and then. Changes to the core code should be posted to the mesa3d-dev list for review. Changes to individual drivers should get buy-in from the driver's maintainer. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkspGLUACgkQX1gOwKyEAw8KcgCgnzH4SM68Sjq5Uvq8lwuJ2yiJ YRcAoJYVs4oJJZV1fsEkANRlrQa8fKnq =eLm0 -END PGP SIGNATURE- -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 25663] Compile Failures on Bluegene/L
http://bugs.freedesktop.org/show_bug.cgi?id=25663
--- Comment #8 from Ben Matthews 2009-12-16 09:32:44 PST ---
Aside from one missed semicolon that branch now compiles with xlc (though I do
see some weird linker warnings at the end)
The fix is here:
diff --git a/src/mesa/main/dlopen.c b/src/mesa/main/dlopen.c
index 325de4b..81e0320 100644
--- a/src/mesa/main/dlopen.c
+++ b/src/mesa/main/dlopen.c
@@ -68,7 +68,7 @@ GenericFunc
_mesa_dlsym(void *handle, const char *fname)
{
#if defined(__blrts)
- return (GenericFunc) NULL
+ return (GenericFunc) NULL;
#elif defined(__DJGPP__)
/* need '_' prefix on symbol names */
char fname2[1000];
Linker error (which I haven't seen/noticed before.. I'm pretty new to xlc)
/bgl/BlueLight/ppcfloor/blrts-gnu/powerpc-bgl-blrts-gnu/bin/ld: warning: cannot
find entry symbol dantic; defaulting to 002000a0
Which I assume is coming from the -pedantic flag here (a couple lines up, but
I'm doing parallel builds so it doesn't take all day so the sequencing is
non-deterministic)
/opt/ibmcmp/vacpp/bg/8.0/bin/blrts_xlc -c -I../../include -O3 -pedantic
-D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE
readtex.c
I have no idea why it's there or what it's supposed to do. Unfortunately I
don't have any easy code to do runtime testing yet (the application of this is
proving even harder to build).
--
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 Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 25663] Compile Failures on Bluegene/L
http://bugs.freedesktop.org/show_bug.cgi?id=25663 --- Comment #7 from Brian Paul 2009-12-16 07:05:19 PST --- OK, I think I've fixed all the code issues. Patches committed to the mesa_7_6_branch branch in git. Can you test that? I didn't touch the installer issues. -- 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 Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 25663] Compile Failures on Bluegene/L
http://bugs.freedesktop.org/show_bug.cgi?id=25663 --- Comment #6 from Brian Paul 2009-12-16 06:58:13 PST --- I'll pick through your patch, clean things up, and make some commits... -- 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 Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): r300g: flush CS if a buffer being deleted is referenced by it
On Wed, Dec 16, 2009 at 02:04:30PM +0100, Michel Dänzer wrote:
> On Tue, 2009-12-15 at 19:04 -0800, Corbin Simpson wrote:
> > Module: Mesa
> > Branch: master
> > Commit: 417ce06306962a9355cbb35cefcdea1951b0ce85
> > URL:
> > http://cgit.freedesktop.org/mesa/mesa/commit/?id=417ce06306962a9355cbb35cefcdea1951b0ce85
> >
> > Author: Marek Olšák
> > Date: Sat Dec 12 23:44:02 2009 +0100
> >
> > r300g: flush CS if a buffer being deleted is referenced by it
>
> [...]
>
> > diff --git a/src/gallium/winsys/drm/radeon/core/radeon_buffer.c
> > b/src/gallium/winsys/drm/radeon/core/radeon_buffer.c
> > index 2a8daed..76acc99 100644
> > --- a/src/gallium/winsys/drm/radeon/core/radeon_buffer.c
> > +++ b/src/gallium/winsys/drm/radeon/core/radeon_buffer.c
> > @@ -131,6 +132,11 @@ static void radeon_buffer_del(struct pipe_buffer
> > *buffer)
> > {
> > struct radeon_pipe_buffer *radeon_buffer =
> > (struct radeon_pipe_buffer*)buffer;
> > +struct radeon_winsys_priv *priv = radeon_buffer->ws->priv;
> > +
> > +if (radeon_bo_is_referenced_by_cs(radeon_buffer->bo, priv->cs)) {
> > +priv->cs->space_flush_fn(priv->cs->space_flush_data);
> > +}
>
> Why would this be necessary?
>
Agree with Michel, this should not be necessary, when
a buffer is added to a cs a reference on it is taken
(at least this what the code used to do) thus the bo will
still be around when the cs is latter flush.
Cheers,
Jerome
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): r300g: flush CS if a buffer being deleted is referenced by it
On Tue, 2009-12-15 at 19:04 -0800, Corbin Simpson wrote:
> Module: Mesa
> Branch: master
> Commit: 417ce06306962a9355cbb35cefcdea1951b0ce85
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=417ce06306962a9355cbb35cefcdea1951b0ce85
>
> Author: Marek Olšák
> Date: Sat Dec 12 23:44:02 2009 +0100
>
> r300g: flush CS if a buffer being deleted is referenced by it
[...]
> diff --git a/src/gallium/winsys/drm/radeon/core/radeon_buffer.c
> b/src/gallium/winsys/drm/radeon/core/radeon_buffer.c
> index 2a8daed..76acc99 100644
> --- a/src/gallium/winsys/drm/radeon/core/radeon_buffer.c
> +++ b/src/gallium/winsys/drm/radeon/core/radeon_buffer.c
> @@ -131,6 +132,11 @@ static void radeon_buffer_del(struct pipe_buffer *buffer)
> {
> struct radeon_pipe_buffer *radeon_buffer =
> (struct radeon_pipe_buffer*)buffer;
> +struct radeon_winsys_priv *priv = radeon_buffer->ws->priv;
> +
> +if (radeon_bo_is_referenced_by_cs(radeon_buffer->bo, priv->cs)) {
> +priv->cs->space_flush_fn(priv->cs->space_flush_data);
> +}
Why would this be necessary?
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 25663] Compile Failures on Bluegene/L
http://bugs.freedesktop.org/show_bug.cgi?id=25663
--- Comment #5 from Ben Matthews 2009-12-16 00:09:01 PST ---
BG/L is more or less Linux based (not AIX at all, though still an IBM product).
The host string is powerpc-bgl-blrts-gnu-gcc. As such, _AIX is not defined.
__blrts and __blrts__ should both be defined instead (at least gcc usually
defines both, I'm not sure how to get xlc to dump it's list of preset macros).
I apologize for missing that you had a public git repository. Normally I would
try that before reporting anything, but I didn't find it the first time through
your website.
This patch against your latest git version seems to fix the xlc build (gcc is
still unhappy about this issue and some of the others -- I can try to figure
that out later):
diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h
index 87c3b2e..4eb249b 100644
--- a/src/mesa/main/compiler.h
+++ b/src/mesa/main/compiler.h
@@ -234,7 +234,7 @@ extern "C" {
#elif defined(__APPLE__)
#include
#define CPU_TO_LE32( x ) CFSwapInt32HostToLittle( x )
-#elif defined(_AIX)
+#elif (defined(_AIX) || defined(__blrts))
#define CPU_TO_LE32( x )x = ((x & 0x00ff) << 24) | \
((x & 0xff00) << 8) | \
((x & 0x00ff) >> 8) | \
--
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 Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
