I’m experiencing a really weird problem…I’ve been playing with the point sprite & point parameters extensions just to came to the conclusion that there’s something wrong there.
After many tests, I’ve reduced the problem to this: “whenever I enable the point sprite extension (no matter where in the code) and start a begin/end block, the GL goes crazy with the texture coordinate generation”.
<…main program loop displaying textured polygons…>
Even if the little point sprite piece of code is executed once before I initialize my engine, Texture Unit 0 will keep generating crazy texcoord values and there’s no way to stop it…even disabling texgen, pushing and popping attribs before and after the point sprite code, NOTHING returns the GL back to the “normal” state.
More things to take into account:
I make nothing but just enabling the extension, start a begin/end block that does nothing, and then disable the extension.
I’m not enabling the GL_COORD_REPLACE_ARB, and I if I do its exactly the same
If I just remove the glBegin/glEnd statements, then everything is OK
If instead of using the begin/end approach I use arrays (glDrawArrays), then everything is OK but the point sprite extension just does not work and the points are rendered without being textured (even if the GL_COORD_REPLACE_ARB is enabled on TU0).
As it’s so easy to reproduce, even without doing “complex” things, I strongly feel it’s a driver problem…could it be?
I’m using an ATI 9700 Pro with Catalyst 4.3 drivers.
im surprised so many people stumble across that bug only recently (didnt try it with 4.1, but 4.2 already had that bug).
also: try using point sprites with vertex array or vbo. most likely not even the point sprites will have correct tex coords (could only get them to work with immediate mode). didnt check if the general tex coord corruption will happen in that case, too.
and if you feel very lucky: try vertex array with more than just a vertex pointer (color pointer worked in my case). when my machine froze and the screen went “signal lost” i guess i managed to crash the card. that didnt happen with vbo (there it simply didnt work) and first i thought its because stupid old me used the vbo offset instead of the pointer. (still, what about the good old access violation?). same happened with the correct pointer and that evening my machine saw more reboots than it usually does in a whole month.
by now ati should have a bunch of emails concerning point sprites (i hope). and maybe they are adequately embarassed about missing a bug like that.
lets hope for 4.4 and maybe somewhere their fixed issues contain something like “dust in game x is now displayed correctly”. but then, as nobody seems to have noticed that bug until a short while ago they might as well say “who cares, nobody is using point sprites anyway”.
Thaks Jared, at least I’m not the only one suffering from this bug
This weekend was a real nightmare, hours and hours thinking what the problem could be and beginning to think I was just stupid for not being able to make point sprites work…never realized it could be a driver problem.
Well, hope ATI fix the problem for the next release.
Sorry for resurrecting an old thread but I’ve run into this problem too and we’re up to Catalyst 4.6. Does ATI have no interest whatsoever in getting these issues resolved? Has anyone been able to get this working on older drivers?
I’ve rebooted my machine hundreds of times today trying to get point sprites working on my Radeon 9800, all I get is lockups (and no VPU won’t recover it) and messed up texcoords on non-point sprite geometry.
I tried Jared’s suggestions (vertex arrays with multiple data pointers) to no avail. This isn’t the first ATI driver bug which hampers my dev time, I haven’t been impressed at all with stability and drivers of this card. Definitely going for a 6800 over a X800 next.
I bugged ATI about this a short while ago, including with my email some simple code, 2 screen shots and the same conclusions above, and was told there would be a fix in the cat4.6 drivers.
drivers get released, bug still exists.
i sent them another email asking basicaly what was going on and attached the SAME code and screen shots as before and got told that apprently they have fixed one issue but the one i’d reported was because of another problem, they’ll get back to me on fix details… currently i’m not holding my breath. :rolleyes:
makes me wonder WHAT problem they fixed? maybe i should try it again with va or vbo? if im lucky they will at least now generate texcoords for the point sprites. and if im really lucky, maybe it wont crash the vpu if i add a colorpointer?
or maybe they just think “point sprites have clipping issues anyway, so who’s needing them?”
i agree, lets not hold our breath, lets just count how many dozen driver versions it will take them to either make them work or at least “officially” remove them.
I told ATI about this damn problem in January. What month is it now? When I report problems to Nvidia (an extremely rare occurrence), I often get fixes the same day. You tell me who cares more about the quality of their drivers.
I’ve got it working with vertex arrays but it crashes randomly. The texcoords on the point sprites do actually work, it’s the rest of them on the same texture unit where GL_COORD_REPLACE_ARB was enabled which get screwed (so maybe that’s not disabling properly?). I tried with glTexEnvf and glTexEnvi just in case but that didn’t do anything.
I think they’ve limited their test cases to some of the demos which are floating around or simple apps they tested on which didn’t include different geometry.
I’d be careful though, when things go wrong this crashes hard.
Originally posted by Eric Lengyel: You tell me who cares more about the quality of their drivers.
question: if ati actually cared about that, how would an obvious bug like that ever get past quality assurance? its not like i usually implement something, compile and ship it without at least a quick test (which in this case would have shown that its simply not working). but then, with developers and customers testing them for you, why waste money on doing it yourself? sigh
maybe their driver programmers double as marketing and are too busy bashing nvidia over something and then implement it themselves with a few changes? gg
Ok, enough of complaints and on to something constructive.
I recently verified a driver bug regarding point sprites together with fragment programs. It worked fine without fragment programs though, and with a slightly hacky workaround worked fine with it too. As I understand most people here though, this is without fragment programs, right?
If anyone have a simple test app with source, send it to me at epersson ‘at’ ati.com and I’ll check it out.
done and done.
I’ve emailed you the same stuff I sent to DevRel back in May and again in June.
Sample app, with source and two screen shots showing the problem.
Originally posted by Cirrus: I’ve got it working with vertex arrays but it crashes randomly. The texcoords on the point sprites do actually work,
then i guess thats the part they fixed.
it’s the rest of them on the same texture unit where GL_COORD_REPLACE_ARB was enabled which get screwed (so maybe that’s not disabling properly?). I tried with glTexEnvf and glTexEnvi just in case but that didn’t do anything.
i tried pushing/popping pretty much every state opengl offers, but whatever is screwed is either hidden well or not accessible.
I think they’ve limited their test cases to some of the demos which are floating around or simple apps they tested on which didn’t include different geometry.
meaning: immediate mode with nothing except the particles, as nothing else worked.
I’d be careful though, when things go wrong this crashes hard.
are you using only vertex pointer or other pointers, too? i only had crashes when using color pointers (and i think even trying it with normal pointers did the same), but then it would always crash and not just sometimes. one out of five tries vpu recover kicked in after an eternity of trying to blindly end it, switch tasks or whatever. of course in that case 2d accel. was lost and i had to reboot anyway.
well, point sprites would be more interesting without the clipping issues anyway.
You’re right, I had VPU recover kick in once last night too after CTRL-ALT-DEL a few times and alt tabbing like mad, but that doesn’t seem to always work.
I tried the vertex arrays with vertex pointers and color pointers (due to your suggestion I was originally only using vertex pointers). I really saw no difference. I was using DrawArrays render.
I think the clipping issues you speak of are inherent to the entire point sprite extension (if a point is off screen it is automatically culled and not clipped to the screen, right?) and not just ATI’s implementation. Is there another issue I don’t know of?
FWIW I ran into this very bug today. Win2k, Radeon 9700,
Catalyst 4.5 though.
ARB_point_sprite with glDrawElements() works, using
glDrawArrays doesn’t work.
I only switched to glDrawElements() after reading this thread,
it immediatly fixed my problems. I had thought it was
shader related as I use GLSL and Cg, but all shaders are
disabled.
Originally posted by Cirrus:
You’re right, I had VPU recover kick in once last night too after CTRL-ALT-DEL a few times and alt tabbing like mad, but that doesn’t seem to always work.
thats why i disabled it by now. either its not working or im forced to reboot to get 2d accel. back anyway, so whats the point. just the fact that a feature like that exists and is considered needed enough to show in the driver settings is slightly unnerving ,-)
I tried the vertex arrays with vertex pointers and color pointers (due to your suggestion I was originally only using vertex pointers). I really saw no difference. I was using DrawArrays render.
hmm… with 4.6 i guess? maybe another thing that has been fixed in the meantime.
I think the clipping issues you speak of are inherent to the entire point sprite extension
yep, that problem isnt ati specific and i sometimes wonder how difficult it would be to turn point into quad before doing the clipping. i guess that would require a vertex shader stage capable of outputting more or less vertices than you put in (and THAT would be feature id love to see ,-) )
Originally posted by glw:
ARB_point_sprite with glDrawElements() works, using
glDrawArrays doesn’t work.
i think i never tried drawelements. at least i would be surprised if i actually created an index array to render a bunch of points.
but dont say doing just that also fixed the other problems (like texturing being screwed after using point sprites… you might not see it right away, but look at a textured quad from an angle for example)
[soapbox]
Vendors sometimes take a LONG time to fix problems. We had a pbuffer problem outstanding with ATI for a year before they could fix it.
Meanwhile, we’ve had a reproducible screen corruption on GeForce 4 outstanding with NVIDIA since October; they claim it’s fixed in series 60 drivers, but they’ve claimed that since February and there’s still no series 60 actually out.
DirectX is no better. Life on the bleeding edge of 3D development means working with half-tested flaky systems, and trying to make it work – even on machines you can never test on yourself. The reason it is like this is that the pace of technology is so fast, nobody has time or can afford to test and ship something solid. The PC business is so price driven, only “barely good enough” will compete and survive. There isn’t even room for someone to charge more and “do it right,” because as soon as you charge more, you’re out of the competition, and have no volume to speak of.
Yes, we’ve found significant bugs in offering from, say, Matrox or 3Dlabs, but their volume is so small, we can’t afford to push the issue with them… quite ironic!
[/soapbox]
Originally posted by jwatte: > they’ve claimed that since February and there’s still no series 60 actually out.
You mean no WHQL certified series 60? I’m using 61.36.
While non certified drivers dont help your customers there’s nothing to stop you downloading them to see if their claim is true.
