unified pipelines, DXn standard?
- Thread starter DOGMA1138
- Start date
It depends on what DirectX Next is going to implement. One possibility for a unified pipeline design is driver/API controlled distribution of pipelines to tasks. Based on the needs of individual applications, a variable number of pipelines may be dedicated to either pixel or vertex processing (or whatever other programmability that is available). If the DirectX Next spec requires that the API control such assignment of pipelines, then a unified architecture is necessary. If there is no such requirement, there may be no need for the spec to want such an architecture and it falls to the IHV to implement pipelines however they feel is best.
WGF 1.0 is not public knowledge yet, let alone WGF 2.0. If the answer is even decided at this point, no one should be writing it here.DOGMA1138 said:
I'm not sure which load balancing you're talking about, since unified pipelines don't exist yet. Maybe you could build an implementation where the driver could help balancing. But I imagine load balancing to happen at a level where the driver couldn't possibly interact with the hardware any more. It would be configurable, but the hardware would decide what to process next, like the scheduler in a CPU decides which instruction to dispatch next.991060 said:
DegustatoR
Legend
Isn't WGF 1.0 basically the same as DX9?Inane_Dork said:
Not to my knowledge, but I should probably get out of the numbers arguments before ATi cards show up. I lost track of that one months ago.DegustatoR said:
WGF names are all to cock at the moment. At present it appears that WGF 1.0 is basically the DX9 requirements for Avalon (the 3D GUI) and WGF 2.0 is DirectX10.0 / DirectX Next. Thats all subject to change though, and probably will do... frequently... as it has already.
Dave B(TotalVR)
Regular
You know I wouldn't be suprised if Series 5 has unified shaders. I remember the term 'parallel processing elements that can be switched in and out for rendering graphics'.
Maybe the reason they are waiting is because they need more spec finalised
Just keeping that memory alive
Maybe the reason they are waiting is because they need more spec finalised
Just keeping that memory alive
Joe DeFuria
Legend
Dave B(TotalVR) said:
It still wouldn't even begin to touch what Rampage would've been!
But man, that Rendition chip... holy crap...Joe DeFuria said:Dave B(TotalVR) said:
It still wouldn't even begin to touch what Rampage would've been!
I heard Rendition was developing tiling technology too, can you picture it?The Baron said:
I don't think you'd want to have the help of the driver. If the load-balancing were based upon a software setting, it could only realistically be changed on a per-pass basis. This may be helpful making, for example, screen-sized quads slightly more efficient, but it's nowhere near the potential benefits for having unified pipelines.991060 said:
I think that the best way to have unified pipelines would be that you have one pipeline, or group of pipelines, work on a triangle from start to finish (well, wouldn't have to exactly be this, but something similar: a truly optimal situation would be one in which all pipelines share one queue which includes both vertices and pixels that need to be calculated). How would this work?
You'd have a dual-state pipeline that operated either in vertex or pixel mode. It simply switches modes depending upon the type of data that next comes through the pipe. One potential problem is that, for efficiency's sake, you'd probably want to have different latency characteristics between the two modes (i.e. data with lots of texture reads and few branches will do better with long latency, whereas data with few texture reads and more branches will do better with shorter latencies). Priority queues may solve this issue, but the question remains as to how many transistors such an implementation requires.
In the end, what does this buy you? Well, it basically means that when an object is far away, and the triangles are pixel-sized or smaller, you won't have pixel pipelines sitting idle. Conversely, you won't have vertex pipelines sitting idle when rendering large triangles.
There is also the potential benefit of requiring less cache. In order to keep vertex and pixel pipelines running as fast as they can, a modern architecture needs to have as much cache between the two as possible. This may no longer be necessary for a unified architecture, though it does have the benefit of also improving memory accesses for pixel data.
Lastly, why go unified? Unified pipelines are a benefit if, and only if, performance turns out to be higher, everything else remaining the same, for a unified architecture with the same number of transistors. Nobody can make this final decision but those making the chips themselves. And it may, in fact, depend upon the microarchitecture of specific products as to whether or not this will be the case.
