Sign in to follow this  
freka586

Rendering speed of pixel-sized triangles?

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this