DirectX 12: The future of it within the console gaming space (specifically the XB1)

I just don't understand why people here refer to DX12 as an "architecture". It's an API. Calling HTML5 an "architecture" will make exactly the same sense.
Modern GPU is a general purpose processor, it can be "programmed" to support any API. The question could be if some of DX12 paths will be fast enough, probably. But that's it.
I know - A wrote a lengthy post many years ago about what DX truly is. For the purposes of discussion, we're talking about hardware that supports, in hardware, the features of the API that enable it to run full tilt. On hardware with suitable hardware features, aspects of the API either don't get implemented in game or run too slow. Hence every time the new DX comes out, it is accompanied by hardware that aims to support it fully, and we get the different DX classes of GPU.

DX is basically a featureset when it comes to talking about hardware.
 
That's right, but I don't see anything that requires specific hardware in current DX12 prospects.
There's the rub! I agree with you and am not seeing hardware requirements, but there are others who feel claims MS customised the HW point to a possibility of the hardware having DX12 specific features. Few of us commenting have any experience with DX12 though and devs weighing in helps a lot. ;) GDC should give some hard references.
 
It's not going to be simple, as in "high level" api that an average level dev will be able to code in .. It's extremely low level , surfacing more of the bare HW for devs to do more with.

They've , MS and OEM partners, have made it clear that Dx12 is now stripped down to the bare bones leaving the app developer to do more work to get even the most basic of rendering ...

And as for minimal, minimal in what sense? Its going to be a thinner layer that does less than what Dx11 drivers do... BUT its not minimal in the sense that devs will need to code more for lack of out of box features in the dx drivers.

Dx12 from everything they've shown/talked to date, is targeted at engine architects, experienced low level devs that are currently hindered with dx11's drivers ..

An API is meant to empower users, to provide the smallest set of commands that will allow programmers to use the hardware as well as possible.
In a nuttshell an API must be small and expressive and not have redudancy (many ways to achieve the same thing).
Whatever happens that API will be an abstraction, no matter how low level it is, so choosing the right level of abstraction (empowering and simple vs uselessly complicated) will be critical.

Simplicity and elegance are usually (but not always) the sign that whomever designed the software masters the subject, the reciprocal is true.
(ie Complicated and inelegant is most often the sign that whomever designed the software doesn't master the subject, and therefore shouldn't have been put in charge.)

[For an exemple case, check source code of many game engines and compare them to iD Tech 4, it will be most telling.]
 
That's not entirely fair. Supporting legacy software often necessitates less than ideal solutions, as can economics. First and foremost, software is a business, not an art. There may be some devs who can engineer superb solutions, but there are plenty of companies working with ordinary people with limited experiences and understanding and finite talent, even if excellent in many ways in their field. A new way of thinking leading to a new software architecture that simplifies the engine/API can't be expected of every project, or even a tiny minority. Such changes tend to be few and far between and only by sharing them (GDC, etc.) that the start of the art is progressed.

Sometimes a complicated, inelegant solution is the right business choice and the one that puts food on the table. Such is the world with all its imperfections that perfect solutions aren't realistic.
 
There's the rub! I agree with you and am not seeing hardware requirements, but there are others who feel claims MS customised the HW point to a possibility of the hardware having DX12 specific features. Few of us commenting have any experience with DX12 though and devs weighing in helps a lot. ;) GDC should give some hard references.

Agreed. I feel as though it'll be subtle additions for a specific types of algorithms that would benefit from dedicated hardware gates/or just additional flag bits in a register as opposed to crunching it through the pipeline. IIRC on this forum, really the last step was to get from rasterization to eventually the quality of ray tracing. There were talks a long time ago that after DX11 there would be no need for another directX, I recall reading this somewhere on this thread, that everything was programmable enough such that there would be no longer a need for additional hardware, just more horsepower.
On that note we see that nvidia is pushing for vxgi, an approximation of ray tracing, I'm not sure how far it can scale, but it shares some characteristics.

I don't know nothing about graphics, aside from some basics, I'll likely never get to a level of understanding that most of you have, or if it happens, it'll occur over the next 6 years as I spend more time learning. But when I look at a graph from nvidia for maxwell 2 that has this:[Anandtech] Joining these features as the final VXGI-centric feature for Maxwell 2 is a feature NVIDIA is calling Multi-Projection Acceleration. A big part of MPA is a sub-feature called viewport multicast. In viewport multicast Maxwell 2 can replay the necessary geometry to all of the viewports in a single pass. At the hardware level this involves giving the hardware the ability to automatically determine when it needs to engage in viewport multicast, based on its understanding of the workload it's receiving.
VoxelPerf_575px.jpg


So when it comes to voxelization, it appears that these features are indeed helpful. These aren't dedicated processors, you probably won't be able to spot these features on a microscope die shot or on a chipworks diagram. As per the chart the software version is completely doable, but even with a 980 Maxwell 2, you could still obtain 3x more performance in this particular scenario if you leveraged the hardware variant of it. The concept of horsepower trumps all only applies to scenarios where power and heat are not an issue, but in the mobile space, in the console space it is an issue, they need other alternatives. They need to do more with less, and having simple additions like this will help.

With respect to this thread, XBOX needs help, like badly. It doesn't have extra CUs to muscle through algorithms, it's power rating is just too low. The more I read, the more I sincerely doubt that MS while building this low power chip decided that yea, 12 CUs are enough to last the next 7 years when all the new techniques like vxgi are coming out. They clearly didn't want to blow their power requirement, so I'm on the side that they've invested in hardware that will allow the console to scale with future techniques and graphical features. If games decide to not take advantage of those techniques and scale with their own methods, we're going to see Xbox slide into uselessness rather fast.
 
Which of latter at least is already covered by current Intel & AMD hardware, isn't it?

I'm going to copy and paste this members comment's from Anandtech. edit: I'm not sure how much of this is accurate, you guys would know better. But from the sounds of this, a lot of this sounds like conformance, not necessarily performance.

  • Posted By: ThatBuzzkiller Posted: 01-24-2015 04:31 AM

    I'd argue that first GPU architecture to fully support the DX 11.3 feature set was none other than GCN ...

    Typed UAV Loads was always capable in mantle with it's uniform buffer supporting full type conversions with R/W operations ...

    Volume tiled resources is just partially resident textures in 3D and GCN does support 3D textures so support for VTR can be easily extended ...

    Conservative rasterization can be performed in the geometry shader so there's no worries there ...

    Raster ordered views is just a fancy way to rename Intel's pixelsync and the feature's name in OpenGL is Intel_fragment_shader_ordering which by the way GCN already supports so ROVs are already covered with GCN ...
 
Last edited:
I'm going to copy and paste this members comment's from Anandtech. edit: I'm not sure how much of this is accurate, you guys would know better. But from the sounds of this, a lot of this sounds like conformance, not necessarily performance.

  • Posted By: ThatBuzzkiller Posted: 01-24-2015 04:31 AM

    I'd argue that first GPU architecture to fully support the DX 11.3 feature set was none other than GCN ...

    Typed UAV Loads was always capable in mantle with it's uniform buffer supporting full type conversions with R/W operations ...

    Volume tiled resources is just partially resident textures in 3D and GCN does support 3D textures so support for VTR can be easily extended ...

    Conservative rasterization can be performed in the geometry shader so there's no worries there ...

    Raster ordered views is just a fancy way to rename Intel's pixelsync and the feature's name in OpenGL is Intel_fragment_shader_ordering which by the way GCN already supports so ROVs are already covered with GCN ...

Conservative rasterization in hardware is much more performant than in software using the geometry shader. See in the topic about shading decoupled from rasterization, read the Intel pdf if you will find a table of performance comparison between an Intel GPU, a Nvidia GPU and an AMD GPU the best performance is on GCN architecture. And they compare software conservative rasterization and hardware conservative rasterization between all GPU . The performance are bad for software rasterization on Nvidia GPU (780), the series 900 solve the problem with hardware conservative rasterization. The best performance is on GCN architecture.

If it is interesting to use software conservative rasterization it is on GCN...

Yes for the other feature. GCN is a very good architecture and is a very good choice for the two consoles it will work well with thin API.
 
Last edited:
Conservative rasterization in hardware is much more performant than in software using the geometry shader. See in the topic about shading decoupled from rasterization, read the Intel pdf if you will find a table of performance comparison between an Intel GPU, a Nvidia GPU and an AMD GPU the best performance is on GCN architecture. And they compare software conservative rasterization and hardware conservative rasterization between all GPU . The performance are bad for software rasterization on Nvidia GPU (780), the series 900 solve the problem with hardware conservative rasterization. The best performance is on GCN architecture.
Where exactly?
I only found this and can't seem to spot any table of performance between Intel, NV and AMD in it?
https://forum.beyond3d.com/threads/shading-decoupled-from-rasterization.56471/#post-1822590
 
Where exactly?
I only found this and can't seem to spot any table of performance between Intel, NV and AMD in it?
https://forum.beyond3d.com/threads/shading-decoupled-from-rasterization.56471/#post-1822590
Sorry

A link to a pdf on this page

https://software.intel.com/en-us/articles/deep-shading-buffers-on-commodity-gpus

Maybe like Voxel Octree or full scene Voxel Cone tracing it will be for next gen console. By full scene I mean not only for scenery like The Tomorrow Children.
 
Conservative rasterization in hardware

I don't think there is one. :)
ALU is a hardware, memory controller is a hardware, but "hardware conservative rasterization" is either a feature of the shader compiler, or a feature of the command processor microcode, both are "software" as far as I see it.
 
I don't think there is one. :)
ALU is a hardware, memory controller is a hardware, but "hardware conservative rasterization" is either a feature of the shader compiler, or a feature of the command processor microcode, both are "software" as far as I see it.

Thanks good to know consoles have probably the hardware to do it after if it is only a question of performance.
 
I don't think there is one. :)
ALU is a hardware, memory controller is a hardware, but "hardware conservative rasterization" is either a feature of the shader compiler, or a feature of the command processor microcode, both are "software" as far as I see it.

GPU fixed function pipelines have dedicated ALU resources and data paths for the conventional rasterizer. Why couldn't there be hardware-level changes in the raster blocks for this?
 
Sorry

A link to a pdf on this page

https://software.intel.com/en-us/articles/deep-shading-buffers-on-commodity-gpus

Maybe like Voxel Octree or full scene Voxel Cone tracing it will be for next gen console. By full scene I mean not only for scenery like The Tomorrow Children.
The "hardware CR" is estimation by intel, apparently such doesn't exist on any of the mentioned chips (does it on maxwell? or is it just improved performance like GCN has nice performance even on the most complex scene?)
 
The "hardware CR" is estimation by intel, apparently such doesn't exist on any of the mentioned chips (does it on maxwell? or is it just improved performance like GCN has nice performance even on the most complex scene?)

I was thinking it exist on Maxwell but I am not a game developer.
 
Adding the word "conservative" to that might lead to a more directly related entry.
I suppose the question is where the setup computations are done for the edge equations passed to the rasterizer.
 
Back
Top