There nothing for the API to support, its just doing an operation in a faster way, why should the API care? It doesn't block it, and it doesn't have anything to support, i.e. the API is as good as it gets... In fact I support you will find that even the hardware command FIFO doesn't even know about it and that the same Draw commands are used, because guess what?! even to the command FIFO hardware it the same operation, "Draw stuff"
C has no explicit raytracking acceleration structures, does it need to change? OCL/CS/CUDA already support raytracing acceleration structures, its the point of 'general' computing, you don't have to specifiy every single thing.
Unless we see fixed function raytracing hardware then no we won't see any change to the API for a specific algorithm. We might see updates to the general compute engine to allow certain operations that assist raytracing (better pointer chasing for example) but nothing specific for at least this spin of the wheel.
Something only need explicit support if its not accessible with the existing API. Many things are added/changed that don't require any changes to support, as such yes they are supported, only if they need extra features do you need to change the API.Once again, the absence of an explicit limitation doesn't imply explicit support. That would mean everything under the sun is supported unless they explicitly state that it's not the case
An perfect example of this is the DX11 texture format that Fermi will add over the last NV chip. Are they supported by the vertex shader? Answer yes but with no explicit support, whereas a generation (or two) ago each vertex texture support required explicit support. So does that mean that D3D is out of date and need updating cos I automagically got the new texture format in the vertex engine?
