Hardware View Frustrum culling---is it possible?

OpenGL OpenGL: Advanced Coding
1

This question is aimed primarily at the nVidia guys but anyone else who has comments about this can also post

OK,I was wondering if it was at all possible if the GPU did all the frustrum cullind operations all in hardware.I mean,since we’re passing all the vertices and faces to the card,and since the card knows our camera’s position,orientation etc,then why couldn’t the card do the frustrum culling all by itself? I’m not talking out of ignorance or anything,but I’m just kind of curious why something like this wouldn’t be possible.Or if it is possible,then why hasn’t it been implemented yet?

Speaking of which,why don’t you guys throw in hardware collision detection while you’re at it

Once again I’m just curious about this.I would love to see hardware frustrum culling in future nVidia cards.This will make coding games and stuff alot easier since frustrum culling will be one less thing the programmer has to worry about (I know,I’m a lazy programmer.So sue me!)

2

Frustum culling, in my opinion, does not belong in the API.

Anything that has to be sent to the HW has to be sent over the bus. So HW frustum culling is bad, because you’ve already wasted lots of CPU cycles copying data.

So that leaves the option of SW frustum culling inside the driver.

But to do SW frustum culling, we need to know your geometry’s bounding volume (box, sphere, …). To know that bounding volume, we either have to scan over your data or have your app tell us what the bounding volume is.

We can’t scan over the data, because that would be inefficient and at best give us an axis-aligned bounding box.

If your app has to tell us what the bounding volume is anyway, and we can’t accelerate the test, the test is best performed by the app.

The general rule is: unless it makes sense to put a feature in HW, it does not belong in a low-level graphics API.

It does not make sense to put frustum culling in HW, because the data has to be moved over the bus.

Therefore, it does not make sense to put frustum culling in a low-level graphics API.

If you look at many of the mistakes made in the design of OpenGL, many of them stem from the failure to recognize this point. It makes no sense to put selection and feedback in HW (though SGI, for some braindead reason, did), but they’re in the API.

Sometimes it makes sense to put a feature in the API even though it is not accelerated at that point in time, but with the anticipation that it will be accelerated in the future. Examples of good design decisions along that line are T&L support, matrix stacks, and (maybe) evaluators.

[Evaluators are a very bad example because they happen to have been horribly misdesigned in several important ways, but at least the intentions were correct: it makes sense to put tesselation features in HW because they alleviate bus bottlenecks.]

  • Matt