On Wed, 2010-03-10 at 06:47 -0800, Corbin Simpson wrote: > I don't know the VBO code that well, so I'm asking you guys if this > has ever come up before. > > http://bugs.winehq.org/show_bug.cgi?id=22000 > > Gallium and indexed rendering are not very happy with each other. I get some > fairly solidly reliable segfaults with both a d3d9 DLL test (device.ok) and > Civ4 (Steam version). Hardware is a Radeon R580 (X1900), driver is r300g from > Mesa git. > > My current guess, based on the Mesa debug info I dumped, is that the indexed > rendering code is slightly baked and maybe trusting the underlying GL driver a > bit too much. > > get_arrays_bounds: Handling 2 attrs > attr 0: stride 16 size 12 start (nil) end 0xfffffffc > attr 1: stride 16 size 4 start 0xc end (nil) > buffer range: (nil) 0xfffffffc range -4 max index 4294967295 > > So right here (from device.ok) we have interleaved userspace VBO, that is > being > prepped inside core Mesa. Two delightful things here; the first attr seems way > off-base, it shouldn't dare be giving us bad pointers, and the second attr's > pointers don't even line up!
In VBO rendering, the pointers are really just offsets into the VBO, so should be interpreted as numbers. The first attribute has what looks like a small negative number. I don't know if that's legal or not in GL - I suspect it is probably not legal and should be rejected in the mesa validation code. I suspect what is happening is wine is passing in some negative values and we aren't properly rejecting them in mesa. > Compare to a sane program (Mesa's drawarrays): > > get_arrays_bounds: Handling 2 attrs > attr 0: stride 16 size 12 start 0x8087020 end 0x808705c > attr 1: stride 16 size 4 start 0x808702c end 0x8087060 > buffer range: 0x8087020 0x8087060 range 64 max index 3 This doesn't look like VBO rendering though. These are regular vertex arrays, meaning these values are proper pointers. > r300g doesn't really care. It shouldn't have to - the expectation in gallium is that inputs have been validated. > The kernel drops the rendering on the floor for a > variety of reasons, not least being the ridiculous max_index. > > But then it segfaults, and I have zero idea why. I'd guess it's something to > do > with tossing around NULL pointers like candy, but I'm honestly not sure and I > haven't really dug into the DLL code yet. It's great you found a bug, but why all the excitement? Just track it down and propose a fix. Mesa's pretty well debugged, but there are always going to be new issues. I'm not sure why it warrants this type of implicit criticism when you come across something new. Keith ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
