Just curious, how many Game Developers are out there (suspectedly) developing a pure D3D (DX?) 10 engine? Since that way they could really leverage the full power of D3D10 without having to "scale" across various hardware. I think Unreal Engine 4 could be a potential candidate. Any ideas?
How many of em are developing with D3D 10?
- Thread starter poly-gone
- Start date
I would imagine it'll only be the R&D guys that are working on this properly. It's too early to be putting any heavyweight resources in (unless you are one of the huge AAA shops - e.g. Epic/Unreal).poly-gone said:
The next generation CryEngine has been shown with a D3D10 path, but no indication as to whether it was pure 10 or just used it. I forget the name, but there is a presentation at this years GDC revealing some WIP of a D3D10 title - but details are suitably sketchy on that one as well.
Despite the fact that some people have had D3D10 a lot longer than it's been public, the fact that there is no hardware (that I know of!) available makes development somewhat challenging. Yes, you can develop on the REFRAST but realistic expectations of the HW are few and far between. The only one I've seen recently is that NV/ATI recommend the GS should only emit a "few dozen" primitives out of the 1024 possible...
Jack
Mordenkainen said:
By the time low-end D3D10 hardware will have sufficiently high user-base (that is 3-4 years from now), Vista requirement might not be an issue...
Until that the only pure engines will be in techdemos and benchmarks.
But I'm sure some developers will start to work on some of those engines as soon as they have hardware.
Does anyone know if D3D10 has any way of specifying that the processing order of primitives (or even batches of primitives) is unimportant?
I.e. can I tell the GPU that for N instances of some object, the order in which the instances (and the triangles within an instance) are rasterized or shaded is completely unimportant?
Basically I'm wondering how parallel the implementation of the GS is going to be - as it stands, it looks like the GS will be operating on a single primitive at a time - is this anywhere near correct?
Serge
I.e. can I tell the GPU that for N instances of some object, the order in which the instances (and the triangles within an instance) are rasterized or shaded is completely unimportant?
Basically I'm wondering how parallel the implementation of the GS is going to be - as it stands, it looks like the GS will be operating on a single primitive at a time - is this anywhere near correct?
Serge
psurge said:
Yes the GS program operates on a single primitive and can output multiple primitives.
It can however use information from adjacent vertices if the topology information is provided (that means more indices per primitive).
OTOH, I don't see why couldn't multiple primitives be run paralelly with apropriate buffering of the output.
arjan de lumens
Veteran
AFAIK, no such mechanism currenty exists. And even if it were to exist, it would run into situations with non-deterministic rendering results, which is a nightmare for both hardware and game developers to deal with.psurge said:
But even with the requrement to emulate strictly serial operation, It isn't really that hard to parallellize GS operation, though: there are standard parallel-computing algorithms/data structures that can handle both parallel generation and fast traversal of variable-length data structures. The main complication is that the number of polygons that the GS can output per input polygon is large; if the number is N (1024 has been mentioned in this thread) and the GS has M threads, then you need to dynamically buffer a section of the generated data with at least N*M polygons, which implies that you pretty much have to be able to use off-chip memory to buffer some of the polygons in the more pathological cases.
Last edited by a moderator:
Jawed
Legend
I get the impression that using off-chip memory is the only way this will work, which is where Stream Out (memexport) comes in.
As I understand it, the GPU is generating a replacement vertex buffer, based on the buffer given to it. Indeed I think the idea is that the GPU generates multiple buffers.
Or, at the very least, the GPU generates an additional buffer to be read back in on a second pass at the same time as the given buffer.
Jawed
As I understand it, the GPU is generating a replacement vertex buffer, based on the buffer given to it. Indeed I think the idea is that the GPU generates multiple buffers.
Or, at the very least, the GPU generates an additional buffer to be read back in on a second pass at the same time as the given buffer.
Jawed
arjan de lumens
Veteran
Off-chip buffers will likely be required for the Geometry Shader to ever reach reasonable performance at a reasonable cost (because of the severe lack of 1:1 correspondence between input and output + the desire to parallellize operation), but there is no need to expose the off-chip buffers/traffic as an API-visible feature, as memexport would be.Jawed said:
The GS output data set can presumably be considered as one vertex buffer generated per input polygon, which is then read back in later (by a 2nd-pass vertex shader or triangle setup or whatever).
arjan de lumens
Veteran
Not quite. In both cases you need to buffer the data at the output of the unit, so that data order can be restored before being presented to the next unit in the pipeline. There are two differences that make the geometry shader much harder to parallellize in practice:3dcgi said:
- The vertex shader outputs a fixed-size data set, while the geometry shader outputs a variable-size data set. This introduces problems with parallelizing processing of output from the geometry shader in a way that has no equivalent with vertex shaders.
- The vertex shader dumps all data at once at the end of the program, whereas the geometry shader can dump data continuously during the entire program invocation. (You can maintain vertex order out of the a vertex shader array extremely cheaply by simply not completing a shader program if such completion would cause out-of-order vertices; a geometry shader array doesn't permit you to do that.)
Unknown Soldier
Veteran
Pete said:Actually, I believe DNF is timed to be exclusively DX10.
* ∞.
Did Not Finish
Gawd .. another year.
US
Similar threads
- Locked
