Keith Whitwell wrote: > 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
Can you post the patch you used to print this info, Corbin? >> 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. This would have come in via the 'ptr' argument to one of the glVertex/Color/etcPointer() functions. We never check for negative pointer values. > 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. -Brian ------------------------------------------------------------------------------ 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
