PDA

View Full Version : feedback render with display list runs slow on ATI



Jan Stalmach
01-21-2008, 09:12 AM
Hi,

we have a very interesting problem with feedback mode rendering when we use display list (DL). The performance is extremely slow on new graphics card. On older ATI X550 it works realy good but on newer ATI HD 2400 XT it works extremely slow. We store our geometry in DL and - for some reasons - we use GL_FEEDBACK mode to obtain xyz components of vertexes. These xyz we use for setting true transformations for our "viewall" function. But this is not problem. The problem is WHY it runs on new ATI so slow? I am wondering if someone of you have some experiences with this problem. What we have to do? Thank you.

knackered
01-21-2008, 11:21 AM
Are you sure it used to be good performance?
GL_FEEDBACK has always traditionally dropped to software. Maybe the newer hardware is shader-only, so now it has to emulate a full shader (the one auto-generated by the driver based on GL state), rather than simply transforming the verts by the modelview/projection (which is all they'd have to do if running a true hardware fixed-function).

V-man
01-21-2008, 11:34 PM
Slow as in 1 or 2 FPS?

And since it is well know that GL_FEEDBACK mode runs in software, you could just do the transform yourself so that you get more consistent performance. Use SSE of course.

Jan Stalmach
01-22-2008, 12:12 AM
Thank you. I know that GL_FEEDBACK is slow, but we use this just for our ViewAll function one time. The interesting is that at ATI X550 it takes 0.2 seconds and at ATI HD 2400XT it takes 10 seconds (We are rendering over milion hits in feedbackbuffer). The same problem is so with traditional OpenGL picking (GL_SELECT mode). I know that ATI never has good support for DL but I am very suprised that new ATI cards have so problems.

Zengar
01-22-2008, 12:36 AM
Well, it is possible that X550 provided some hardware support for feedback and selection (although I can't believe it) or at least some optimized software support. Still, both of this modes are actually deprecated, they are atavisms from the past and should be avoided. I suggest you transform the vertices on the CPU, should be trivial to implement, and should run fast even without

msteen
02-19-2008, 01:00 PM
Hi Jan

I have the same problem with an ATI 2600 card. It seems that
this lag does not happen when using vertex buffer objects.

GL_FEEDBACK and GL_SELECT worked fine with older ATI
cards like 9800pro, 9600 and ATI laptop chipsets.
Looks like ATI messed it up.

Greetings, Martin

Jan Stalmach
02-20-2008, 08:37 AM
I have made a small GLUT app and if I just put one vertex to feedback buffer so the speed on ATI HD degrade 10 times! The information about pure vertex arrays is fine but is really hard to avoid all of glvertex calls... Are you sure that this solved the problem and what about select buffer? Try to render 100 gluquadric object into select buffer on ATI and the horror starts! Why ATI rewrited drivers with these incredible bugs?

Korval
02-20-2008, 11:13 AM
Why ATI rewrited drivers with these incredible bugs?

While I would never say that ATi's drivers are bug-free, the slowness of software modes like feedback and selection isn't a bug. These are not performance features, and implementations will make them however slow they want.

msteen
02-21-2008, 03:29 AM
No matter if you call it a bug, a glitch or whatever: it's
a strange behaviour of the graphcics card of driver.
The Intel GMA-3000 onboard graphics seems to have this problem
either.

Drawing 8000 vertices in GL_FEEDBACK mode takes about 4
seconds on our test-machine (core2 4500, ATI 2600, WinXP)
Sometimes. Sometimes it takes 0.01 seconds. It seems like this
has something to do with glDrawElements or display lists.
If we use glVertex3fv calls only (no display lists, no
glDrawElements), the code runs fast
(have to do more tests to proof it).

Greetings, Martin

Zengar
02-21-2008, 04:00 AM
Martin, as I already said this modes are de-facto deprecated. So just don't use them.

knackered
02-21-2008, 04:12 AM
it will be gone when gl-forever is released.

msteen
02-21-2008, 07:02 AM
Martin, as I already said this modes are de-facto deprecated. So just don't use them.

Thats easier said than done. Transform the vertices on the CPU
is not an option because we need depth buffer information too.

GL_SELECT/GL_FEEDBACK modes are well testet, are easy to use
and work fast and stable on all cards we used so far, except ATI 2xxx/3xxx and some new Intel chipsets.
So why drop them? Maybe I should mail ATI to ask them when they go to fix their drivers.

Zengar
02-21-2008, 07:38 AM
So why drop them? Maybe I should mail ATI to ask them when they go to fix their drivers.

I guess they won't care. I surely wouln't care if someone asks me to fix a deprecated feature... besides, ATI has lots otehr things to fix that are way more improtant.

And you can always transform on CPU (it is done so by driver anyway) and readback the depth buffer if you need.

tapted
02-23-2008, 04:00 AM
Zengar: do you have a pointer to something that says this feature (i.e. glRender(GL_SELECT) ) is deprecated?

It would surprise me if it is. See, this is meant to be the beauty of open standards -- features do not just "get deprecated" because a vendor decides to stop implementing it. Being able to rely on a standard is a programmers' necessity so that they can use standard features without *having* to worry about them being deprecated in the future without a very good reason.

Transforming on the CPU is obviously insufficient if, indeed, this is what ATI's drivers have been doing. My tests have shown a sequence of operations taking 5 seconds with the new drivers, where before it would take 50ms. Slowing things down 100-fold is obviously not an option.

My current hope is that this is just a bug that ATI have introduced into their drivers just after (internal) version 8.401. It sucks that this also happens to be the last version before HD support came in. Looks like I might be stocking up on X1950s..

And this does, indeed, appear to be what is happening. Upgrading catalyst drivers on Windows and Linux on any number of cards (I've tested X1950, X600, 9600 and X850XT) utterly breaks glRender(GL_SELECT). I'm trying to track this down -- see

http://www.it.usyd.edu.au/~tapted/slow_glselect.html

There is a cross-platform test program there. You can cross-compile it, or I'll probably put up a Windows binary for the lazy.

For now, I'm informing clients not to upgrade their graphics drivers, or to get an old version from

http://ati.amd.com/support/drivers/xp/radeonxprevious-xp.html

I'm still testing Windows. Certainly, the latest catalyst driver (8.2) has the problem. In Linux, ati-drivers-8.40.4 is the last version that has a working GL_SELECT. If versions match up this might correspond to Catalyst 7.8 being the last working version for Windows.

I've started the tedious process of reporting it to ATI using their support pages. I've had two "responses" -- boilerplate that shows they obviously haven't actually read the ticket description. Frustrating.

If it doesn't get fixed, I'll certainly have to avoid ATI cards like the plague in any future development I do. And... if my research goes to market, it would definitely not be using ATI cards.

Zengar
02-23-2008, 04:23 AM
It is very simple: the GL drivers are very complicated to write as they are, and there is no way a driver developer will waste time on feature that is not really needed or used. GL has many such features that originate from it "workstation API" roots: selection mode (unflexible), feedback mode (more or less useless if card can't do render-to-vertex-array because slow), accumulation buffer (can be easily emulated with shaders -- actually it is accelerated on last cards via shaders). A graphics API is there to provide access to accelerated hardware features, not more and not less.

It is possible that ATI emulated feedback mode in hardware, as their cards can do scatter-writes for quite some time now. But is is also possible that the new drivers had this feature removed because it is just a waste of time to implement: there are no serious applications that rely on it. Hence, you shouldn't use it either.

Komat
02-23-2008, 07:59 AM
It would surprise me if it is. See, this is meant to be the beauty of open standards -- features do not just "get deprecated" because a vendor decides to stop implementing it. Being able to rely on a standard is a programmers' necessity so that they can use standard features without *having* to worry about them being deprecated in the future without a very good reason.

The feature still works. Just it is not as fast as you are expecting it to be. The ATI completely rewrote its OpenGL driver so it is very likely that for rarely used features such as this, they implemented the simplest possible solution which is still compliant with the specification.

It the speed is an issue, you can write your own optimized hit testing functions or use occlusion queries depending on what data about the hit you need to know.

Rsantina
09-08-2009, 02:10 AM
Does anyone know a good document that show the alternative methods for each deprecated feature