Rendering speed of pixel-sized triangles?
Author
As I have written in a bunch of older topics, I am having troubles with writing depth values manually.
Unfortunately I cannot count on D16Lockable format being available.
I am currently exploring DEPTH output in the pixel shader,
but would also like some comments on another approach.
To not be dependent on caps for DEPTH writes in the pixel shader I am thinking about rendering pixel-sized triangles to generate depth information.
But if the resolution is, say 1000x1000 pixels this will be quite a few triangles!
What performance can I expect?
Is there *any* other way to safely generate depth buffer info from an array of depth values?
If one imagines the depth info as a height map, could this perhaps be approximated with some triangularization?
What do you think of spatial resolution and performance of such an approach?
Perhaps,
Instead of telling us your solution, perhaps tell us what the over-all goal you are trying to accomplish? It seems you need to get access to the depth buffer, but why? We could probaly tell you the way to go about it- or not go about it .
-Dave Neubelt
Instead of telling us your solution, perhaps tell us what the over-all goal you are trying to accomplish? It seems you need to get access to the depth buffer, but why? We could probaly tell you the way to go about it- or not go about it .
-Dave Neubelt
Rendering pixel size triangles is very slow. You will be setup-limited, which is usually 2-4 clocks per triangle. So, just take your core gpu clock and divide by 4 to give you an idea of the # of pixels you can draw per second.
Author
OK, sorry for jumping to conclusions...
I am doing SW volume rendering using raycasting.
The finished rendering must contain depth information, so that HW rendered arrows or text information can be blended properly afterwards.
Since this is part of a slow SW pass, the speed of generating depth information isn't *that* critical.
Even depth render times approaching a second could be tolerable.
If SimmerDs approximation is valid, rendering 1M pixe-sized triangles should at *most* be in the order of 1/10sec, right?
Any other potential bottle necks that could cause longer speeds than that?
I am doing SW volume rendering using raycasting.
The finished rendering must contain depth information, so that HW rendered arrows or text information can be blended properly afterwards.
Since this is part of a slow SW pass, the speed of generating depth information isn't *that* critical.
Even depth render times approaching a second could be tolerable.
If SimmerDs approximation is valid, rendering 1M pixe-sized triangles should at *most* be in the order of 1/10sec, right?
Any other potential bottle necks that could cause longer speeds than that?
If you only intend to render "text and arrows" besides the volumes, it could be worthwhile to make use of a software rasterizer for them too. You do have the volume depth bitmapped? Use the same map for the other rendering as well.
Depending on the complexity of the other stuff you draw, the above approach can work surprisingly well. The hardware can't really do much for you in this situation.
Depending on the complexity of the other stuff you draw, the above approach can work surprisingly well. The hardware can't really do much for you in this situation.
Author
I knew this suggestion was going to show up :)
For some reasons I'd like to avoid SW rendering of widgets if at all possible.
First, I need to render them in HW anyway for other reasons.
Keeping both HW and SW renderers of all widgets causes loads of code to maintain and support.
It also makes it more cumbersome to add more widgets (more complicated ones) later on.
So, I completely agree with you that SW rendering of widgets is a very tempting idea, and a good solution in most cases.
But in my specific situation it is something that I would like to avoid if at all possible.
For some reasons I'd like to avoid SW rendering of widgets if at all possible.
First, I need to render them in HW anyway for other reasons.
Keeping both HW and SW renderers of all widgets causes loads of code to maintain and support.
It also makes it more cumbersome to add more widgets (more complicated ones) later on.
So, I completely agree with you that SW rendering of widgets is a very tempting idea, and a good solution in most cases.
But in my specific situation it is something that I would like to avoid if at all possible.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
