Bad display list performance and solutions

OpenGL OpenGL: Advanced Coding
1

Hi Folks,

I’m using display lists in my application. For the most part, everything works well. However, I’ve noticed that the process of generating my display list is very slow on a particular graphics card, the Matrox Parhelia 128MB. Using this card, it takes several seconds to generate my display list, whereas on the other cards (ATI, NVidia, …) this happens instantaneously.

I’m wondering;

  1. Does this seem unreasonable? I know that vendors implement display lists in different ways. Maybe I’m doing something wrong?

  2. Assuming that there is nothing wrong with my code, what is the best way to deal with this situation?

I was considering the following approach. Generate a small display list, measure the amount of time taken. If this time falls below a certain tolerance, then disable the use of display lists in my code.

This doesn’t seem like the cleanest approach, but I can’t think of anything better to do at this point.

Thoughts, comments?

Thanks,
Dan

2

Welcome to the world of PC hardware.

Our “solution” to this problem is to do extensive compatibility testing using a dedicated QA lab, and use the output to drive a text file which sets various capability bits based on various “strstr” results on the GL_VENDOR/GL_RENDERER.

You’ll find that for the Intel i845/i830 driver, they’ll happily accept any number of display lists, but once they’re out of whatever their pre-allocated buffer is, they just seem to drop them on the floor. Thus, we don’t use display lists when we see this hardware.

We just started testing the Parhelia, and the shipped drivers rebooted the computer when our program loaded. The latest drivers on the web run, but all textures show up wrong; it looks like a problem with compressed texture handling. It’s useful to know that we need to look at display list performance, too. Have you also tried compressed textures on the Parhelia?

3

Matrox? Pah!
Did anyone actually buy the parhelia?

4

Wow, sounds like a lot of work. Are there any databases with information like this publicly available? It would seem to be in the best interest of developers to share knowledge about such things.

No, I haven’t tried any textures with the Parhelia. I am working on a Chemistry application, and we don’t use textures.

I should download the latest Matrox drivers and see if the display list problem just goes away.

Thanks for the input!

Dan

5

Originally posted by jwatte:
You’ll find that for the Intel i845/i830 driver, they’ll happily accept any number of display lists, but once they’re out of whatever their pre-allocated buffer is, they just seem to drop them on the floor.

jwatte-

There is no pre-allocated buffer, so that’s not the cause of your problem. Do you have a simple app that you can send me that demonstrates the behavior that you’re seeing?

Thanks,
– Ben

6

Unfortunately, no. All simple test cases work just fine. The project I’m working on is rather complex and chews through all kinds of OGL resources with wild abandon in an asynchronous fashion that varies between invocations :-/ It could even turn out to be our own code, although it runs well on most other drivers and we’ve analyzed glTrace output and the program itself fairly thoroughly. The only hint I have is that we use wglShareLists().

We’re actually working with Intel dev guys (I suppose you’re one :slight_smile: under the wraps of NDA to get our bugs fixed, so I’d rather just keep going through that channel; I can’t really give details here. But thanks for offering!