From: Jose R. <jos...@gm...> - 2007-10-29 20:13:31
|
Hi I can't run Gtkradiant (http://www.qeradiant.com/cgi-bin/trac.cgi) with the radeon driver and the following hardware/software: 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] Libraries and driver from Debian testing (6.6.193-3 driver's version) Libraries and driver from Debian unstable (6.7.195-2 driver's version) The program crashes as soon as I try to use it, and the following is read in its console: Lighting mode requires OpenGL features not supported by your graphics drivers: GL_ARB_shader_objects GL_ARB_vertex_shader GL_ARB_fragment_shader GL_ARB_shading_language_100 After it crashes the following appears in the terminal: radiant.x86: vbo/vbo_split_inplace.c:97: flush_vertex: Assertion `max_index >= min_index' failed. Aborted I've been told in the Gtkradiant mailing list that it's a driver issue, specifically: "[...]older Radeon cards have only the ability to address up to 4096 vertices at a time [...] GTKRadiant is issuing more than this many vertices in one call. The hardware however has configurable base address for vertex arrays, and configurable index bias, this allows it to issue the large draw operation as several smaller ones that do not violate the limits of the hardware. That error indicates the code for splitting the operations into smaller ones, is broken. (All other drivers have to deal with this sort of hardware limitation transparently as well, it's not an application error)" And been encouraged to report this here. I would like to ask for confirmation that there's no workaround possible short of fixing code (which I have no idea about). Thanks |
From: Roland S. <sr...@tu...> - 2007-10-29 21:50:21
|
Jose Rodriguez wrote: > Hi > > I can't run Gtkradiant > (http://www.qeradiant.com/cgi-bin/trac.cgi) with the radeon > driver and the following hardware/software: > > 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 > [Mobility Radeon 9600 M10] > > Libraries and driver from Debian testing (6.6.193-3 driver's > version) > Libraries and driver from Debian unstable (6.7.195-2 > driver's version) > > The program crashes as soon as I try to use it, and the > following is read in its console: > > > Lighting mode requires OpenGL features not supported by your > graphics drivers: GL_ARB_shader_objects > GL_ARB_vertex_shader > GL_ARB_fragment_shader > GL_ARB_shading_language_100 > > > After it crashes the following appears in the terminal: > > > radiant.x86: vbo/vbo_split_inplace.c:97: flush_vertex: Assertion > `max_index >= min_index' failed. Aborted > > > I've been told in the Gtkradiant mailing list that it's a driver > issue, specifically: > > "[...]older Radeon cards have only the ability to address up to > 4096 vertices at a time [...] strictly speaking, that's not a chip limitation, but a driver limitation. Even oldest radeon could address 65536 vertices at a time. You have a much newer radeon though which could address 4 billion vertices in theory... > GTKRadiant is > issuing more than this many vertices in one call. > > The hardware however has configurable base address for vertex > arrays, and configurable index bias, this allows it to issue the > large draw operation as several smaller ones that do not violate > the limits of the hardware. > > That error indicates the code for splitting the operations into > smaller ones, is broken. > > (All other drivers have to deal with this sort of hardware > limitation transparently as well, it's not an application error)" > > And been encouraged to report this here. I would like to ask for > confirmation that there's no workaround possible short of fixing > code (which I have no idea about). Yes, that certainly looks like a driver error, possibly in the vbo code but could be r300 specific. You could try a newer r300 dri driver (note the radeon ddx version is irrelevant here). Also, could you provide a backtrace from gdb? What are the max_index and min_index values? Roland |
From: Jose R. <jos...@gm...> - 2007-10-30 02:34:32
|
On Mon, 29 Oct 2007 22:50:06 +0100 Roland Scheidegger <sr...@tu...> wrote: > Jose Rodriguez wrote: > > Hi > > > > I can't run Gtkradiant > > (http://www.qeradiant.com/cgi-bin/trac.cgi) with the radeon > > driver and the following hardware/software: > > > > 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 > > [Mobility Radeon 9600 M10] > > > > Libraries and driver from Debian testing (6.6.193-3 driver's > > version) > > Libraries and driver from Debian unstable (6.7.195-2 > > driver's version) > > > > The program crashes as soon as I try to use it, and the > > following is read in its console: > > > > > > Lighting mode requires OpenGL features not supported by your > > graphics drivers: GL_ARB_shader_objects > > GL_ARB_vertex_shader > > GL_ARB_fragment_shader > > GL_ARB_shading_language_100 > > > > > > After it crashes the following appears in the terminal: > > > > > > radiant.x86: vbo/vbo_split_inplace.c:97: flush_vertex: > > Assertion `max_index >= min_index' failed. Aborted > > > > > > I've been told in the Gtkradiant mailing list that it's a > > driver issue, specifically: > > > > "[...]older Radeon cards have only the ability to address up to > > 4096 vertices at a time [...] > strictly speaking, that's not a chip limitation, but a driver > limitation. Even oldest radeon could address 65536 vertices at a > time. You have a much newer radeon though which could address 4 > billion vertices in theory... > > > GTKRadiant is > > issuing more than this many vertices in one call. > > > > The hardware however has configurable base address for vertex > > arrays, and configurable index bias, this allows it to issue > > the large draw operation as several smaller ones that do not > > violate the limits of the hardware. > > > > That error indicates the code for splitting the operations into > > smaller ones, is broken. > > > > (All other drivers have to deal with this sort of hardware > > limitation transparently as well, it's not an application > > error)" > > > > And been encouraged to report this here. I would like to ask > > for confirmation that there's no workaround possible short of > > fixing code (which I have no idea about). > Yes, that certainly looks like a driver error, possibly in the > vbo code but could be r300 specific. > You could try a newer r300 dri driver (note the radeon ddx > version is irrelevant here). Thanks for replying. I´m not sure what do you mean by "ddx" but I guess it's the version number I provided for the Debian drivers. If that is not relevant, what is? Actually, there was a typo in my original mail, I should've said "experimental" instead of "unstable". That driver was released on 09/10/07 to the experimental branch. I don't know if that's the date the snapshot was taken, but it should be pretty recent though. If still there was something to be gained by compiling the drivers from git let me know--I assume this is what you have in mind when saying "newer" ones. > Also, could you provide a backtrace > from gdb? What are the max_index and min_index values? > > Roland Right, after googling a good while I came up with the following thing, although it looks like it's rubbish. I installed the xserver-xorg-video-ati-dbg and libc6-dbg packages and upgraded the driver to its 6.6.1.193-3 version (released on 07/09/07) since it was a dependency. I don't know how to tell the system to look for the debug libraries where they get installed. I trid to put symlinks to /usr/lib/debug where the regular driver is but X wouldn't start. Please let me know how can I obtain more useful information than what follows: This GDB was configured as "i486-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) set pagination 0 (gdb) run Starting program: /home/jcarlos/software/other/GtkRadiant_old/ins tall/radiant.x86 Failed to read a valid object file image from memory. [Thread debugging using libthread_db enabled] [New Thread 0xb71ee6c0 (LWP 10633)] radiant.x86: vbo/vbo_split_inplace.c:97: flush_vertex: Assertion `max_index >= min_index' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 0xb71ee6c0 (LWP 10633)] 0xb747d7d6 in raise () from /lib/libc.so.6 (gdb) thread apply all bt full Thread 1 (Thread 0xb71ee6c0 (LWP 10633)): #0 0xb747d7d6 in raise () from /lib/libc.so.6 No symbol table info available. #1 0xb747f0f1 in abort () from /lib/libc.so.6 No symbol table info available. #2 0xb7476b50 in __assert_fail () from /lib/libc.so.6 No symbol table info available. #3 0xb6ad65b1 in ?? () from /usr/lib/dri/r300_dri.so No symbol table info available. #4 0xb6b46bc1 in ?? () from /usr/lib/dri/r300_dri.so No symbol table info available. #5 0xb6b46ba9 in ?? () from /usr/lib/dri/r300_dri.so No symbol table info available. #6 0x00000061 in ?? () No symbol table info available. #7 0xb6ad6a3e in vbo_split_inplace () from /usr/lib/dri/r300_dri .so No symbol table info available. #8 0xb6a2bad9 in _tnl_draw_prims () from /usr/lib/dri/r300_dri.s o No symbol table info available. #9 0xb6a24ce5 in ?? () from /usr/lib/dri/r300_dri.so No symbol table info available. #10 0x0914ee48 in ?? () No symbol table info available. #11 0x091982f0 in ?? () No symbol table info available. #12 0xbfb0c5e0 in ?? () No symbol table info available. #13 0x00000001 in ?? () No symbol table info available. #14 0x00000000 in ?? () No symbol table info available. (gdb) As an exercise, I fired up Gtkradiant (a map editor for a number of 3D games) and draw a cube, duplicated it, duplicated those two afterwards, then again until I had 2e13 cubes. (I guess this is 2e15 vertices). I don't know by heart how many vertices a normal project usually has, but I have the feeling that much less (I can't check for obvious reasons). The program didn't crashed but I didn't continue for it was sucking my cpu quite badly. While doing this I monitored what happened with gdb and found that from start Gtkradiant was falling back to software rendering. If anything of this is of any help I'll happily post whatever information. |
From: Michel <mi...@tu...> - 2007-10-30 07:05:11
|
On Tue, 2007-10-30 at 02:33 +0000, Jose Rodriguez wrote: > > I´m not sure what do you mean by "ddx" [...] The X driver. For 3D, usually only the Mesa driver is relevant. > I installed the xserver-xorg-video-ati-dbg and libc6-dbg packages [...] You need to install libgl1-mesa-dri-dbg or build from mesa Git. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer |
From: Jose R. <jos...@gm...> - 2007-10-30 12:09:03
|
>On Mon, 29 Oct 2007 22:50:06 +0100 >Roland Scheidegger <sr...@tu...> wrote: > Also, could you provide a backtrace > from gdb? What are the max_index and min_index values? Er...not sure, there are a couple of values for each. Take a look below, please. On Tue, 30 Oct 2007 08:05:00 +0100 Michel Dänzer <mi...@tu...> wrote: > On Tue, 2007-10-30 at 02:33 +0000, Jose Rodriguez wrote: > > > > I´m not sure what do you mean by "ddx" [...] > > The X driver. For 3D, usually only the Mesa driver is relevant. Oh, I didn't know. Libgl1-mesa-dri version is 7.0.1-2. > > I installed the xserver-xorg-video-ati-dbg and libc6-dbg > > packages [...] > > You need to install libgl1-mesa-dri-dbg or build from mesa Git. Thanks a lot, installing that package made a change. This is what I get now: This GDB was configured as "i486-linux-gnu"... setUsing host libthread_db library "/lib/libthread_db.so.1". (gdb) set pagination 0 (gdb) run Starting program: /home/jcarlos/software/other/GtkRadiant_old/install/radiant.x8 6 Failed to read a valid object file image from memory. [Thread debugging using libthread_db enabled] [New Thread 0xb718c6c0 (LWP 5135)] radiant.x86: vbo/vbo_split_inplace.c:97: flush_vertex: Assertion `max_index >= m in_index' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 0xb718c6c0 (LWP 5135)] 0xb741b7d6 in raise () from /lib/libc.so.6 (gdb) thread apply all bt full Thread 1 (Thread 0xb718c6c0 (LWP 5135)): #0 0xb741b7d6 in raise () from /lib/libc.so.6 No symbol table info available. #1 0xb741d0f1 in abort () from /lib/libc.so.6 No symbol table info available. #2 0xb7414b50 in __assert_fail () from /lib/libc.so.6 No symbol table info available. #3 0xb6a745b1 in flush_vertex (split=0xbf974840) at #vbo/vbo_split_inplace.c:97 min_index = 0 max_index = 5135 __PRETTY_FUNCTION__ = "flush_vertex" #4 0xb6a74a3e in vbo_split_inplace (ctx=0x8ac8518, #arrays=0x8b11dd8, prim=0xbf9 74ba0, nr_prims=1, ib=0x0, min_index=0, max_index=4294967295, draw=0xb69c9970 <_ tnl_draw_prims>, limits=0xbf974ad8) at vbo/vbo_split_inplace.c:255 split = {ctx = 0x8ac8518, array = 0x8b11dd8, prim = 0xbf974ba0, nr_prims = 1, ib = 0x0, min_index = 0, max_index = 4294967295, draw = 0xb69c9970 <_tnl_d raw_prims>, limits = 0xbf974ad8, dstprim = {{mode = 6, indexed = 0, begin = 1, e nd = 1, weak = 0, pad = 0, start = 0, count = 0}, {mode = 0, indexed = 0, begin = 0, end = 0, weak = 0, pad = 0, start = 0, count = 0} <repeats 31 times>}, dstp rim_nr = 1} #5 0xb69c9ad9 in _tnl_draw_prims (ctx=0x8ac8518, #arrays=0x8b11dd8, prim=0xbf974 ba0, nr_prims=1, ib=0x0, min_index=0, max_index=4294967295) at tnl/t_draw.c:384 limits = {max_verts = 3000, max_indices = 4294967295, max_vb_size = 4294 967295} tnl = (TNLcontext *) 0x8b23688 #6 0xb69c2ce5 in vbo_exec_DrawArrays (mode=6, start=0, count=0) #at vbo/vbo_exec _array.c:259 ctx = <value optimized out> prim = {{mode = 6, indexed = 0, begin = 1, end = 1, weak = 0, pad = 0, s tart = 0, count = 0}} #7 0x081c3026 in RenderablePatchWireframe::render #(this=0x996ccb0, state=128) a t radiant/patch.h:221 n = 0 #8 0x081f78a1 in Renderables_flush (renderables=@0x892cfd4, #current=@0xbf974e14 , globalstate=65675, viewer=@0xbf974ef4) at radiant/renderstate.cpp:2183 i = {_M_current = 0xa486cbc} transform = (const Matrix4 *) 0x9d1ac68 #9 0x081f7b23 in OpenGLStateBucket::render (this=0x892cf50, #current=@0xbf974e14 , globalstate=65675, viewer=@0xbf974ef4) at radiant/renderstate.cpp:2220 No locals. #10 0x08204e56 in OpenGLShaderCache::render (this=0x8447138, #globalstate=65675, modelview=@0x8590000, projection=@0x858ffc0, viewer=@0xbf974ef4) at radiant/rend erstate.cpp:1427 i = {_M_node = 0x892cff8} current = {m_state = 128, m_sort = 0, m_texture = 0, m_texture1 = 0, m_t exture2 = 0, m_texture3 = 0, m_texture4 = 0, m_texture5 = 0, m_texture6 = 0, m_t exture7 = 0, m_colour = {m_elements = {1, 1, 1, 1}}, m_blend_src = 770, m_blend_ dst = 771, m_depthfunc = 513, m_alphafunc = 519, m_alpharef = 0, m_linewidth = 1 , m_pointsize = 1, m_linestipple_factor = 1, m_linestipple_pattern = 43690, m_fo g = {mode = 2048, density = 0, start = 0, end = 0, index = 0, colour = {m_elemen ts = {1, 1, 1, 1}}}, m_program = 0x0} pattern = "����UUUU����UUUU����UUUU����UUUU����UUUU����UUUU����UUUU����U UUU����UUUU����UUUU����UUUU����UUUU����UUUU����UUUU����UUUU����UUUU \000\000\000" #11 0x08270bba in XYRenderer::render (this=0xbf974fa8, #modelview=@0x8590000, pro jection=@0x858ffc0) at radiant/xywindow.cpp:2128 No locals. #12 0x08268bf3 in XYWnd::XY_Draw (this=0x858ff30) at #radiant/xywindow.cpp:2286 renderer = {<Renderer> = {_vptr.Renderer = 0x82aa528}, m_state_stack = { <std::_Vector_base<XYRenderer::state_type,std::allocator<XYRenderer::state_type> >> = {_M_impl = {<std::allocator<XYRenderer::state_type>> = >> {<__gnu_cxx::new_al locator<XYRenderer::state_type>> = {<No >> data fields>}, <No data fields>}, _M_sta rt = 0xa211228, _M_finish = 0xa211230, _M_end_of_storage = 0xa211248}}, <No data fields>}, m_globalstate = 65675, m_state_selected = 0x8457760} nDim1 = 1 nDim2 = 2 globalstate = 65675 #13 0x0826b537 in xywnd_expose (widget=0x85d1a10, #event=0xbf975600, xywnd=0x858f f30) at radiant/xywindow.cpp:809 No locals. #14 0xb7ad4c10 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 No symbol table info available. #15 0x085d1a10 in ?? () No symbol table info available. #16 0xbf975600 in ?? () No symbol table info available. #17 0x0858ff30 in ?? () No symbol table info available. #18 0xb76dd738 in ?? () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #19 0xb7ad4bb0 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 No symbol table info available. #20 0x08590430 in ?? () No symbol table info available. #21 0xbf9750c8 in ?? () No symbol table info available. #22 0xb76ac619 in g_closure_invoke () #from /usr/lib/libgobject-2.0.so.0 No symbol table info available. Backtrace stopped: frame did not save the PC (gdb) |
From: Roland S. <sr...@tu...> - 2007-10-30 13:01:16
|
Jose Rodriguez wrote: >> On Mon, 29 Oct 2007 22:50:06 +0100 >> Roland Scheidegger <sr...@tu...> wrote: >> Also, could you provide a backtrace >> from gdb? What are the max_index and min_index values? > > Er...not sure, there are a couple of values for each. Take a look > below, please. > #5 0xb69c9ad9 in _tnl_draw_prims (ctx=0x8ac8518, > #arrays=0x8b11dd8, prim=0xbf974 > ba0, nr_prims=1, ib=0x0, min_index=0, max_index=4294967295) at > tnl/t_draw.c:384 limits = {max_verts = 3000, max_indices = > 4294967295, max_vb_size = 4294 967295} > tnl = (TNLcontext *) 0x8b23688 > #6 0xb69c2ce5 in vbo_exec_DrawArrays (mode=6, start=0, count=0) > #at vbo/vbo_exec > _array.c:259 > ctx = <value optimized out> > prim = {{mode = 6, indexed = 0, begin = 1, end = 1, weak = > 0, pad = 0, s tart = 0, count = 0}} > #7 0x081c3026 in RenderablePatchWireframe::render > #(this=0x996ccb0, state=128) a > t radiant/patch.h:221 > n = 0 Hmm, so max_index is -1. Apparently gtkradiant has called drawArrays with a count of 0 (which is legal though pretty much a no-op), it seems we don't handle that correctly. (calculating start + count - 1 is a problem there...). I'd guess the solution for that is checking for count == 0 and returning early in vbo_exec_DrawArrays in this case. Maybe the same problem can be found in other places, haven't really looked at it (e.g. the drawelements functions). Roland |
From: Jose R. <jos...@gm...> - 2007-10-31 12:37:33
|
On 30/10/2007, Roland Scheidegger <sr...@tu...> wrote: > > Hmm, so max_index is -1. Apparently gtkradiant has called drawArrays > with a count of 0 (which is legal though pretty much a no-op), it seems > we don't handle that correctly. (calculating start + count - 1 is a > problem there...). I'd guess the solution for that is checking for count > == 0 and returning early in vbo_exec_DrawArrays in this case. Maybe the > same problem can be found in other places, haven't really looked at it > (e.g. the drawelements functions). > > Roland > Should I open a bug report about this? Would building DRI from git make any difference? Is there anything else I could do in terms of a) providing information and b) solving my inability to run this software? Thanks for your time Jose |
From: Alex D. <ale...@gm...> - 2007-10-31 13:34:06
|
On 10/31/07, Jose Rodriguez <jos...@gm...> wrote: > On 30/10/2007, Roland Scheidegger <sr...@tu...> wrote: > > Hmm, so max_index is -1. Apparently gtkradiant has called drawArrays > > with a count of 0 (which is legal though pretty much a no-op), it seems > > we don't handle that correctly. (calculating start + count - 1 is a > > problem there...). I'd guess the solution for that is checking for count > > == 0 and returning early in vbo_exec_DrawArrays in this case. Maybe the > > same problem can be found in other places, haven't really looked at it > > (e.g. the drawelements functions). > > > > Roland > > > > > Should I open a bug report about this? Would building DRI from git make any > difference? Is there anything else I could do in terms of a) providing > information and b) solving my inability to run this software? yes, please file a bug for this. Alex |
From: Roland S. <sr...@tu...> - 2007-10-31 13:56:18
Attachments:
drawarrayzerocount.diff
|
Jose Rodriguez wrote: > On 30/10/2007, *Roland Scheidegger* <sr...@tu... > <mailto:sr...@tu...>> wrote: > > Hmm, so max_index is -1. Apparently gtkradiant has called drawArrays > with a count of 0 (which is legal though pretty much a no-op), it seems > we don't handle that correctly. (calculating start + count - 1 is a > problem there...). I'd guess the solution for that is checking for count > == 0 and returning early in vbo_exec_DrawArrays in this case. Maybe the > same problem can be found in other places, haven't really looked at it > (e.g. the drawelements functions). > > Roland > > > > Should I open a bug report about this? Would building DRI from git make > any difference? Is there anything else I could do in terms of a) > providing information and b) solving my inability to run this software? git master still would have the same problem as far as I can see. The attached simple patch might fix the problem, if it really is what I think it is :-). I'm a bit unsure if DrawElements might have a similar problem, the same problem shouldn't happen but maybe others later... Roland |
From: Brian P. <bri...@tu...> - 2007-10-31 15:37:52
|
Roland Scheidegger wrote: > Jose Rodriguez wrote: >> On 30/10/2007, *Roland Scheidegger* <sr...@tu... >> <mailto:sr...@tu...>> wrote: >> >> Hmm, so max_index is -1. Apparently gtkradiant has called drawArrays >> with a count of 0 (which is legal though pretty much a no-op), it seems >> we don't handle that correctly. (calculating start + count - 1 is a >> problem there...). I'd guess the solution for that is checking for count >> == 0 and returning early in vbo_exec_DrawArrays in this case. Maybe the >> same problem can be found in other places, haven't really looked at it >> (e.g. the drawelements functions). >> >> Roland >> >> >> >> Should I open a bug report about this? Would building DRI from git make >> any difference? Is there anything else I could do in terms of a) >> providing information and b) solving my inability to run this software? > > git master still would have the same problem as far as I can see. > The attached simple patch might fix the problem, if it really is what I > think it is :-). > I'm a bit unsure if DrawElements might have a similar problem, the same > problem shouldn't happen but maybe others later... > > Roland > > > ------------------------------------------------------------------------ > > diff --git a/configs/linux-debug b/configs/linux-debug > diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c > index 1e4c310..abe5741 100644 > --- a/src/mesa/vbo/vbo_exec_array.c > +++ b/src/mesa/vbo/vbo_exec_array.c > @@ -240,6 +240,9 @@ vbo_exec_DrawArrays(GLenum mode, GLint s > if (!_mesa_validate_DrawArrays( ctx, mode, start, count )) > return; > > + if (!count) > + return; > + > FLUSH_CURRENT( ctx, 0 ); > > if (ctx->NewState) The proper fix is to do the check in _mesa_validate_DrawArrays() as is done for DrawElements and DrawRangeElements. I'll take care of it. -Brian |
From: Roland S. <sr...@tu...> - 2007-10-31 15:57:47
|
Brian Paul wrote: > Roland Scheidegger wrote: >> git master still would have the same problem as far as I can see. >> The attached simple patch might fix the problem, if it really is what I >> think it is :-). >> I'm a bit unsure if DrawElements might have a similar problem, the same >> problem shouldn't happen but maybe others later... >> >> Roland >> >> >> ------------------------------------------------------------------------ >> >> diff --git a/configs/linux-debug b/configs/linux-debug >> diff --git a/src/mesa/vbo/vbo_exec_array.c >> b/src/mesa/vbo/vbo_exec_array.c >> index 1e4c310..abe5741 100644 >> --- a/src/mesa/vbo/vbo_exec_array.c >> +++ b/src/mesa/vbo/vbo_exec_array.c >> @@ -240,6 +240,9 @@ vbo_exec_DrawArrays(GLenum mode, GLint s >> if (!_mesa_validate_DrawArrays( ctx, mode, start, count )) >> return; >> >> + if (!count) >> + return; >> + >> FLUSH_CURRENT( ctx, 0 ); >> >> if (ctx->NewState) > > The proper fix is to do the check in _mesa_validate_DrawArrays() as is > done for DrawElements and DrawRangeElements. I'll take care of it. Ah right. Thought it's only used for checking if the arguments are legal (due to the function name), not if they are legal but lead to no-op. Apparently that's not the case... Roland |
From: Jose R. <jos...@gm...> - 2007-11-07 00:46:23
|
This is indeed now solved. I hadn't understood whether action had been taken when I filled the bug report. I did build DRI from git and Gtkradiant works as it should. Let me thank you all for your work. The professionality I found here is way beyond anything I saw before. I guess it couldn't be any other way for what your doing. Thanks again. Jose Rodriguez |