Software rasterisers and their performance
Author
I apologise for the quadruple posts. I was running woodchuck's app which I couldn't close and I was pressing all sorts of key combos. IE was running in the background and it somehow posted the message 4 times. In the end I had to do a hard reboot. :D Maybe it's divine justice for responding in an impolite manner...
Polygon count is a bad factor for comparing software rendering performance (although Pixomatic gives you some numbers on its site). There is only one bottleneck of importance; the pixel pipeline.
Recall that early graphics cards (and some modern integrated graphics cards as well), did't perform T&L in hardware and were able to render high-complexity scenes. Also, Doom 3 uses the CPU to construct shadow volumes. So this indicates that geometry processing is, in general, not that big an issue.
In my experience, the number of clock cycles required to process a vertex or a pixel are roughly equal. So at a 1024x768 resolution, you'd need almost a million vertices to make the vertex pipeline a bottleneck. Most applications don't even have a million vertices in the whole scene!
Of course, if you were referring to a software renderer like the ones used in 3D Studio MAX or AutoCAD, then the vertex pipeline is probably of highest importance...
Recall that early graphics cards (and some modern integrated graphics cards as well), did't perform T&L in hardware and were able to render high-complexity scenes. Also, Doom 3 uses the CPU to construct shadow volumes. So this indicates that geometry processing is, in general, not that big an issue.
In my experience, the number of clock cycles required to process a vertex or a pixel are roughly equal. So at a 1024x768 resolution, you'd need almost a million vertices to make the vertex pipeline a bottleneck. Most applications don't even have a million vertices in the whole scene!
Of course, if you were referring to a software renderer like the ones used in 3D Studio MAX or AutoCAD, then the vertex pipeline is probably of highest importance...
Quote:Original post by bah
THIS IS A REPOST FROM THE LOUNGE.
Good morning,
How many open source or commercial software rasterisers (or simply your own pet projects) do you know of and how do they perform? How many triangles and of what type (textured, lit, smooth shaded, etc) can they render per second?
I'd like to compare them to my own rasteriser to see if there is room for improvement (i.e. researching new, more efficient algorithms for performing parts of the rendering pipeline).
Thanks
P.S. I assume that a software rasteriser renders geometric primitives to a buffer and then passes it on to the underlying 3D API (i.e. glDrawPixels()).
Renderman comes to mind as the predominant rasterizer. Though there are also raytracing 'compatible' varients.
Author
I thought my initial post was quite clear, yet I was wrong.
C0D1F1ED
I am talking about "software rasterisers" which I defined in my first post to avoid any confusion.
glDrawPixels is an OpenGL function that writes a block of pixels to the frame buffer.
All in all, I am an average Joe that created a rasteriser and simply wants to compare it to other rasterisers that other average Joes and Janes around the world have created.
Also, the reason I posted to this forum was because I figured that some of the more advanced graphics programmers might have implemented their own rasteriser as an exercise and could comment on its performance.
C0D1F1ED
I am talking about "software rasterisers" which I defined in my first post to avoid any confusion.
Quote:
P.S. I assume that a software rasteriser renders geometric primitives to a buffer and then passes it on to the underlying 3D API (i.e. glDrawPixels()).
glDrawPixels is an OpenGL function that writes a block of pixels to the frame buffer.
All in all, I am an average Joe that created a rasteriser and simply wants to compare it to other rasterisers that other average Joes and Janes around the world have created.
Also, the reason I posted to this forum was because I figured that some of the more advanced graphics programmers might have implemented their own rasteriser as an exercise and could comment on its performance.
bah, there are still different classes of software rasterizer. The two extremes would be Pixomatic and Renderman. The first is aimed at real-time approximated rendering of previous generation games, while the second is aimed at highly accurate rendering of professional movie scenes. So if you want to compare your rasterizer with another one we have to know what class it's in.
Anyway, I assumed you've created a real-time software rasterizer. In that case, as I previously mentioned, polygon count is a bad measure of performance.
My own real-time software renderer, swShader is entirely fillrate limited even though the vertex and pixel pipelines use dynamically generated assembly code. You can download the demos to compare performances.
Do you have any demos of your rasterizer? Then we might be able to spot performance bottlenecks and give you advice. What are your long-term goals with this rasterizer?
Anyway, I assumed you've created a real-time software rasterizer. In that case, as I previously mentioned, polygon count is a bad measure of performance.
My own real-time software renderer, swShader is entirely fillrate limited even though the vertex and pixel pipelines use dynamically generated assembly code. You can download the demos to compare performances.
Do you have any demos of your rasterizer? Then we might be able to spot performance bottlenecks and give you advice. What are your long-term goals with this rasterizer?
Here's a screenshot from my rasteriser:
Clicky for all shots
It's not blazingly fast - that renders at ~30FPS on my PC (2.4GHz P4, 512MB RAM, all at 640x480) and uses SDL. However, it's affine texturemapping only so far and if you try and render, say, a box with you inside it (so every pixel on screen is drawn) it drops to ~5FPS. [sad]
The models are nicked from DOOM3.
Clicky for all shots
It's not blazingly fast - that renders at ~30FPS on my PC (2.4GHz P4, 512MB RAM, all at 640x480) and uses SDL. However, it's affine texturemapping only so far and if you try and render, say, a box with you inside it (so every pixel on screen is drawn) it drops to ~5FPS. [sad]
The models are nicked from DOOM3.
benryves :
try this , you can have it for the same "price" (in term of performance) that your affine rasterizer :
http://www.d6.com/users/checker/misctech.htm
But i agree, for models like that, it's not necessary... hope that help even.
try this , you can have it for the same "price" (in term of performance) that your affine rasterizer :
http://www.d6.com/users/checker/misctech.htm
But i agree, for models like that, it's not necessary... hope that help even.
Quote:Original post by Woodchuck
benryves :
try this , you can have it for the same "price" (in term of performance) that your affine rasterizer :
http://www.d6.com/users/checker/misctech.htm
But i agree, for models like that, it's not necessary... hope that help even.
[smile] Thanks!
Actually, one of the problems was that the model loading code caused an error whenever the program ended and I could not find it. If I ever get around to building a more solid loader, I'll certainly look into it.
Author
Quote:
bah, there are still different classes of software rasterizer. The two extremes would be Pixomatic and Renderman. The first is aimed at real-time approximated rendering of previous generation games, while the second is aimed at highly accurate rendering of professional movie scenes. So if you want to compare your rasterizer with another one we have to know what class it's in.
Ok, I'll tell you what my rasteriser does. It renders about 40k triangles, fully lit (8 lights, phong illumination model), textured and bilinearly shaded at around 60 frames/second. The triangles are part of a bezier patch, which is generated algorithmically and regenerated per frame (i.e. multiple memory allocations/deallocations per frame), and the results were achieved whilst running in Visual Studio's (version 6.0) debug mode. There are a few other things that the demo is doing in the background such as animating the lights and patch which affect the frame rate.
They triangles are also clipped against the frustum.
[Edited by - bah on March 29, 2005 6:31:32 PM]
That ain't bad!
Did you use any specific optimizations like assembly code or approximating the lighting formulas (attenuation, local viewer)?
Did you use any specific optimizations like assembly code or approximating the lighting formulas (attenuation, local viewer)?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement