Gtkradiant not working with radeon driver

2007-10-29 Thread Jose Rodriguez
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

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Gtkradiant not working with radeon driver

2007-10-29 Thread Roland Scheidegger
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

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Gtkradiant not working with radeon driver

2007-10-29 Thread Jose Rodriguez
On Mon, 29 Oct 2007 22:50:06 +0100
Roland Scheidegger <[EMAIL PROTECTED]> 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  0x0061 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

Re: Gtkradiant not working with radeon driver

2007-10-29 Thread Michel Dänzer

On Tue, 2007-10-30 at 02:33 +, 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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Gtkradiant not working with radeon driver

2007-10-30 Thread Jose Rodriguez
>On Mon, 29 Oct 2007 22:50:06 +0100
>Roland Scheidegger <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:

> On Tue, 2007-10-30 at 02:33 +, 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} }, 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 = 
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 ([EMAIL PROTECTED],
[EMAIL PROTECTED]
, globalstate=65675, [EMAIL PROTECTED]) at
radiant/renderstate.cpp:2183 i = {_M_current = 0xa486cbc}
transform = (const Matrix4 *) 0x9d1ac68
#9  0x081f7b23 in OpenGLStateBucket::render (this=0x892cf50,
[EMAIL PROTECTED]
, globalstate=65675, [EMAIL PROTECTED]) at
radiant/renderstate.cpp:2220 No locals.
#10 0x08204e56 in OpenGLShaderCache::render (this=0x8447138,
#globalstate=65675, 
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED])
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 =
"U
UUU
\000\000\000"
#11 0x08270bba in XYRenderer::render (this=0xbf974fa8,
[EMAIL PROTECTED], pro
[EMAIL PROTECTED]) at radiant/xywindow.cpp:2128
No locals.
#12 0x08268bf3 in XYWnd::XY_Draw (this=0x858ff30) at
#radiant/xywindow.cpp:2286
renderer = { = {_vptr.Renderer = 0x82aa528},
m_state_stack =
{ 

>> = {_M_impl = {> =
>> {<__gnu_cxx::new_al locator> = {> data fields>}, }, _M_sta
rt = 0xa211228, _M_finish = 0xa211230, _M_end_of_storage =
0xa211248}}, }, m_globalstate = 65675,
m_state_selected = 0x8457760} nDim1 = 1
nDim2 = 2
globalstate = 65675
#13 0x0826b537 in xywnd_expose (widget=0x85d1a10,
#ev

Re: Gtkradiant not working with radeon driver

2007-10-30 Thread Roland Scheidegger
Jose Rodriguez wrote:
>> On Mon, 29 Oct 2007 22:50:06 +0100
>> Roland Scheidegger <[EMAIL PROTECTED]> 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 = 
> 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

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Gtkradiant not working with radeon driver

2007-10-31 Thread Jose Rodriguez
On 30/10/2007, Roland Scheidegger <[EMAIL PROTECTED]> 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
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Gtkradiant not working with radeon driver

2007-10-31 Thread Alex Deucher
On 10/31/07, Jose Rodriguez <[EMAIL PROTECTED]> wrote:
> On 30/10/2007, Roland Scheidegger <[EMAIL PROTECTED]> 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

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Gtkradiant not working with radeon driver

2007-10-31 Thread Roland Scheidegger
Jose Rodriguez wrote:
> On 30/10/2007, *Roland Scheidegger* <[EMAIL PROTECTED]
> > 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)
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Gtkradiant not working with radeon driver

2007-10-31 Thread Brian Paul
Roland Scheidegger wrote:
> Jose Rodriguez wrote:
>> On 30/10/2007, *Roland Scheidegger* <[EMAIL PROTECTED]
>> > 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

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Gtkradiant not working with radeon driver

2007-10-31 Thread Roland Scheidegger
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

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Gtkradiant not working with radeon driver

2007-11-06 Thread Jose Rodriguez
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
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel