I have a small OpenGL program that measures the time to send polygons to the driver :
// start clock
start = getClock();
// send polygons
sendPolygons();
// measure time
time = getClock() - start;
with wireframe disabled, time = 5 ms
with wireframe enabled, time = 180 ms
i find these results very strange because the number of calls to the OpenGL API is exactly the same in both cases and therefore the CPU should spend the same amount of time writing into the driver FIFO.
Note that i don’t call glFinish before timing because i want to measure the time to send the commands and not the actual rendering time (i know that drawing in wireframe is slower)
Could it be that the command buffer is flushed by the implementation, and it’s making an implicit call (equivalent to) glFinish?
Depending on hardware, the speed of drawing lines could theoretically (as I’ve never seen it IRL) be as fast as or even faster than fill mode, or it could be much, much slower (that, I have seen ).
How many measurements have you done? There may be some external factors causing temporary delay?
I assume that majority of cards that are not directly designed for use in professional modeling software do not support lines in HW.
In that case the OpenGL implementation imho must generate two triangles to draw single line from wireframed image and if it does not contain optimizations for this rarely (at least in gamming word) used case, there may be 6 triangles generated for each triangle you specified.
The generation of line triangles may take some time and if triangles were specified using method other than immediate mode (e.g. VBO) the retrieval of vertex positions may take more time than for immediate mode (e.g. if VBO is stored in memory of the card)
Additionally increased ammount of vertex data may fill buffers requiring them to be send to the driver.
thanks for your reply
i wish i could also hear opinion from nvidia engineers. They are really the only ones to know for sure what is going on in the driver
i have a GeForce 5950 Ultra
WinXP, ForceWare 77.72
I’ve noticed that lines tend to be slower also. I always assumed that this was because there was less hardware dedicated to line drawing than to triangle drawing on the chip.
High level professional level cards actually have as one of their selling points as faster line drawing (for people doing CAD stuff or 3D work).
he’s not talking about the speed of drawing, he’s talking about the speed of submitting the primitives to be drawn. Drawing with lines should affect the total frame time, not the command issue time.
in general, when submitting OpenGL commands to the driver, i find it hard to understand if the time spent is only the time to fill the FIFO (assuming i never call glGetxxx functions which stall the CPU). What happens when the FIFO is full ? Does the driver wait for the GPU ?
Originally posted by knackered: he’s not talking about the speed of drawing, he’s talking about the speed of submitting the primitives to be drawn. Drawing with lines should affect the total frame time, not the command issue time.
If the app is filling the OpenGL fifo then the app will block waiting for the fifo to empty so the timings can vary dramatically.
Changing the example so is sends a smaller batch of OpenGL commands would make it less likely that the fifo would fill, and therefore less likely that the app would report such dramatic differences.
This would change whats happening down in the OpenGL driver or GPU w.r.t handling wireframe polygon fill mode. My own experience is that the Nvidia drivers/GPU don’t handle polygon fill mode efficiently compared to normal polygon fill mode. This does mean that the fifo does get emptied far slower, in turn making it more likely that its possible to fill the fifo and for your app to block.
Originally posted by Stephen_H:
[b]I’ve noticed that lines tend to be slower also. I always assumed that this was because there was less hardware dedicated to line drawing than to triangle drawing on the chip.
High level professional level cards actually have as one of their selling points as faster line drawing (for people doing CAD stuff or 3D work).[/b]
Remember that when drawing in wireframe mode you lose the benefits of early-z culling.
Some graphics cards convert wireframe data to very thin triangles or quads to avoid implementing specialized wireframe circuitry. It could be that the driver is doing this conversion during the submit and would/could entail a fairly significant amount of cycles to take each line segment and convert into a compatible trianglated form. If that is what’s happening, then it’s definitely going to be slower than simply moving the data.
“High end cards” tend to have dedicated hardware to handle wireframe data and it helps tremendously if the wireframe is wider than a pixel, antialiased, or has any form of vertex coloring (e.g., depth cueing, etc.). Of course the last time I looked at this in detail was several years ago and the feature set differences between consumer cards and professional cards is becoming increasingly blurred – and not always to the good of the professional card
Originally posted by tranders: Some graphics cards convert wireframe data to very thin triangles or quads to avoid implementing specialized wireframe circuitry.
Nah, that would require them to software transform the verts…and the lines would not look correct, and would not blend correctly. I don’t think that would adhere to the opengl specification either, so it couldn’t be called opengl support.
Originally posted by knackered: Nah, that would require them to software transform the verts…and the lines would not look correct, and would not blend correctly. I don’t think that would adhere to the opengl specification either, so it couldn’t be called opengl support.
You may not believe it but it is true for many of the earlier cards. While most cards may have supported single pixel wide lines directly through minimalist hardware, wide lines or specially rendered lines may be more easily implemented by converting the lines to polygons. Heres a quote from an HP Starbase technical document circa 1997:
Filled widelines are rendered by taking the single-pixel-width line segment and performing some calculations to generate a polygonal description of the wideline line segment. This polygonal description is then passed to the device’s polygon rasterizer for rendering. Linetyped widelines require much more computation and are slower to render. Similarly, color per vertex and depth-cued vectors are slower to render.
While this is from a pretty old Starbase X11 technical document, I’m reasonably sure that the same hardware also supported OpenGL. FWIW, it is well known that early OpenGL hardware failed many of the OpenGL conformance tests and some graphics cards simply didn’t display “stylized” wireframe data at all. A vendor’s implementation can “fail” certain tests and still be considered OpenGL compliant because OpenGL is not a pixel perfect specification. The primary litmus test is reproducible results with a given set of inputs/parameters.
Based on the 30x reduction in throughput, this seems like a possible answer for this person’s configuration. Of course only the vendor could provide the real reason.
).