[milk]

Originally Posted by Frenetic Pony

8k tv's are already planned for before then, and it will probably happen too.

As for voxels/ray tracing for any kind of primary (geometry) purpose/shading, that rings somewhat of fusion. It seems great in hypothetical scenarios, and then when you get right down to working around it practically it just falls apart.

I'm sure we'll have unlimited detail and realtime raytracing someday, just like we'll be running our PCs off our neighborhood fusion plants someday. But for the foreseeable future there's just too much overhead, especially for things like storage of voxels as art assets. Not too mention other people want all that compute power for simulation stuff. Frankly I'd rather see this in a game: http://www.youtube.com/watch?v=47riga-OVro than spend all those resources just to make it so I could use raytracing.

I could see voxels beeing used in plenty of defferred rendered games for particles, special weird looking and very detailed objects, volumetric clouds and dust, and other things of that type. Now most of the environment, and its long flat concreet walls, and skinned animated characters will probably stick to polygons for a long time.

[Frenetic Pony]

Originally Posted by milk

I could see voxels beeing used in plenty of defferred rendered games for particles, special weird looking and very detailed objects, volumetric clouds and dust, and other things of that type. Now most of the environment, and its long flat concreet walls, and skinned animated characters will probably stick to polygons for a long time.

Oh sure sure, I'd love to see it for particles, the current billboards (even with all their hacks) just don't cut it. And both Cryengine 3 and Unreal Engine 4 use a voxel data structure for global illumination, and UE4 even uses cone tracing for GI.

I was more referring to the discussion going towards such being used primarily as opposed to our classic vertex/pixel/what have you programs and polygons.

[sebbbi]

Originally Posted by rpg.314

AFAIK, the tessellator in xbox 360 is mostly unused. Would you say that it has disadvantaged non-tessellated geometry rendering?

Yes of course. If they had chosen not to include the tessellator those transistors could be spent to other features (such as one extra shader ALU), or just be removed (to improve yields and manufacturing costs, and thus reducing the console price). Simple as that. This is the exact reason why I feel that adding large amount of fixed function transistors for features that are not yet being established (such as real time raytracing) is not a good decision. It will be a hit or a miss. A big gamble really.

If huge amount of transistors are spend to some rendering technique that's not yet proven to be usable, there's always the risk of not giving developers what they exactly want. There will be limitations that nobody though about, because the rendering technique wasn't yet widely used and researched thoughout. Also the fixed function hardware solution is likely going to result in less research in alternative techniques, and that's not a good thing, if one of the alternative techniques proves to be better in the long run.

Basically you should only use fixed function hardware for established tasks, that are thoroughly researched, the "best" solution for the problem exists, is agreed by most developers and the task is commonly used in huge majority of games. Good examples: texture samplers, triangle setup, CPU caches, math (sqrt, exp, estimates...), texture decompression, depth buffering (including hierachial depth and depth compression), general purpose compression/decompression (LZ-style), video decompression (for parts that benefit most from FF hardware), audio mixing...

---

I purposefully left MSAA out of the above list. Let me explain it a bit.

Efficient 4xMSAA means that you have to:
1. 4x fixed function point-inside-triangle hardware
2. 4x fixed function depth testing hardware
3. 4x fixed function stencil testing hardware
4. 4x fixed function blending hardware
5. 4x wider data path from rops to memory (but not any wider from PS to rops)
6. More memory and more memory bandwidth (for backbuffer operations) and/or MSAA color compression an depth compression (again more fixed function hardware)

That's a lot of hardware. And MSAA is only used by small minority of current generation console games (and not in all PC games either). Even in those games that use MSAA, the MSAA hardware is only used for around 20% of the time (rendering objects to g-buffers). It does nothing for 80% of the time (it's not needed in shadow map rendering, lighting and post processing).

Current PC GPUs solve the MSAA backbuffer bandwidth demands with depth and color compression hardware (more fixed function hardware), and the rest is solved by making rops (much) fatter. Xbox 360 solved the problem with EDRAM. It had the required bandwith and built in fixed function processors for blending/z-buffering/stenciling. EDRAM solved all the six requirements.

Now let me talk about shadow map rendering. It's an operation that is heavily fill rate bound. In games that have lots of dynamic shadow casting lights, shadow map rendering can take up to 30% of the frame time. Shadow map rendering mainly requires fixed function depth buffering hardware (and storing depth samples to render target). These are the main bottlenecks of it. GPUs with 4xMSAA have four times more fixed function depth buffering hardware (and bus/bw/compression to store the depth values). That must be a very good thing for shadow mapping? Will it provide 4x depth fill rate?

Unfortunately no... You can render the shadowmap to 4xMSAA buffer, and have proper separate depth testing to each subpixel and have 4x fillrate. However the fixed function point-inside-triangle testers have fixed offsets (optimized MSAA pattern), and these offsets do not form a regular grid. So the sampling from the rendered shadowmap texture is not straightforward. Even the simplest nearest neighbor sampling requires excessive amount of math (dozens of instructions). Because one of the six fixed function components is not up to the task (1), all the others (2-6) are pretty much unusable as well for shadow mapping. What a shame.

The lesson here is: Even if some rendering technique is currently very popular (MSAA antialiasing), it might suddenly become a niche because of new research (deferred shading). MSAA depth testing hardware would be very good for shadow map rendering (4x fill rate), but because a single small mistake in the FF hardware design it cannot be used for shadow map rendering at all (two sets of MSAA sample offsets, and a flag to select preferred one would be enough to solve the issue). ---> Fixed function hardware is very fragile. Even tiny limitations in it might make it unusable.

All this extra fixed function hardware for 4xMSAA makes rops very fat. Current generation consoles have only eight rops, and thus are often fill rate bound. I would trade all that MSAA hardware for 16 rops any day (and even that would halve the fixed function hardware listed). EDRAM has the bandwidth, that's not a problem.

Originally Posted by itsmydamnation

when power is the major constraining factor why do we care about utilisation? FF will be "king" so long as it allows continued progress while offering ultimately Superior performance. If utilisation was the key metric VLIW never would have happened. being able to do whatever you want however you want has a price too, larrabee wasn't able to pay the price of admission .

VLIW happened. Separate vertex and pixel shaders also happened...

Processors with VLIW such as Intel Itanium and Transmeta Crusoe are dead. Itanium was always plagued with heat problems. GPUs with VLIW are going the same route: NVidia dropped both VLIW and separate pixel and vertex shaders in Geforce 8000 series, and we all know how that story ended (8800 is one of the most popular graphics hardware ever). AMD kept VLIW alive for longer, but dropped it in GCN. So VLIW is as good as dead (in both CPU and GPU markets).

Utilization is important. Pentium 4 pipeline was long to allow very high clocks. It's very hard to keep a long pipeline properly utilized. Intel's Core 2 architecture came up with a much shorter pipeline that allowed much higher hardware utilization. P4 had much higher theoretical peak numbers, but the improved utilization was the key to both good performance and good efficiency. Thus Core 2 was the biggest jump in perf/watt we have ever seen in CPUs.

---

Also you have to think about chip manufacturing costs. Each fixed function unit requires some extra transistors. And these transistors have very low utilization ratio (are idling most of the time even in software that uses them). These units also require separate design (research cost), while you can often just replicate the programmable units many times to scale up the performance, and slighly improve the design from generation to another. Replication is also a boon for programmable units, because of the yields. You can just add a few extra programmable units to improve yields (and thus lower production costs). A programmable unit can replace any programmable unit if there is a defect in the chip manufacturing. For fixed function units, you need to have a separate spare for each fixed function unit type (a broken video decoder cannot be replaced by anything else, so you might need to have two of them in the chip just to improve yields). Additional broken programmable units often only degrade the performance, while the feature set stays the same. This provides an cost effective method for selling hardware for lower price points.

[sebbbi]

The thing that annoys me most in fixed function hardware is that it limits my freedom. Fixed function hardware (and ratio of different FF hardware) is designed for the needs of an average game (usually last generation game, since hardware development takes time), and if your game is anything different, the hardware doesn't suit your needs that well. Games are different, and have different hardware requirements. Programmable hardware allows game developers to implement the game they want, not something that hardware manufacturer has planned for them. Creative freedom is important for good quality games. We need more different games, not hardware limitations that force us to do things in certain way.

I have been a graphics programmer since 3dfx era (Voodoo, Riva 128, TNT, etc are familiar for me). Ever since fixed function T&L came, graphics hardware has had major limitations compared to software graphics engines. You just had to cope with the limitations and invent creative hacks to get the required graphics features implemented. The time period when half of the cards supported EMBM (environment mapped bump mapping) and half of the cards supported DOT3 bumpmapping is something I really want to forget. Luckily DX8 was released, and we finally got shaders that allowed us to implement either one, and much much more. I have seen the golden age of fixed function graphics programming, and I don't want to go back there. Most of the things graphics programmers were doing back then was hacking their way around fixed function hardware limitations.

The way tessellation was implemented in DX11 API isn't that bad really. Domain shaders and hull shaders are written with the same language as all the other shaders and utilize the same programmable hardware. Only the part of the system that spawns new GPU work items is fixed function. We don't have yet programmable way to spawn work items on GPU, so this is understandable. But (in the future) when we get a proper way to do that, there might no longer be a need for separate hull and domain shaderes. Of course that is what I also want from the future.

Fixed function hardware bottlenecks are a real thing. When thinking about our last console project, I think that we were bottlenecked by triangle setup, texture sampling, vertex fetch, ALU, fill rate (rops), texture caches and BW . All in different stages of our scene rendering. Shadow map rendering for example was rop bound for near objects and triangle setup or vertex fetch bound for far away objects (depending on object type). Object rendering was texture sampling bound for some objects, texture cache bound for some (reflective), vertex fetch bound for some (high polygon far away) and ALU bound for some (very near objects with heavy shaders). Deferred lighting was ALU bound, and post processing was texture sampling bound. Most of the time during the frame we were bottlenecked by some fixed function unit. ALU was sitting there doing nothing during that time, and we were still heavily ALU bound during lighting. That's what happens when you have too many different bottlenecks (different fixed function units). We of course did some creative hacks to for example reduce vertex fetching bottlenecks (compress vertices, and burn some ALU to decompress) and to reduce texture fetching / BW bottlenecks (encoding/decoding), but optimizations like this were only a win for some cases, so the combination of shaders increased, and debugging and profiling time increased drastically. This is what you have to do in order to cope with the GPU fixed function bottlenecks. It takes lots of programming resources = makes games cost more to develop.

[PeterAce]

Thanks for the last two posts sebbbi. They were an absolute joy to read

[3dcgi]

Originally Posted by sebbbi

Yes of course. If they had chosen not to include the tessellator those transistors could be spent to other features (such as one extra shader ALU), or just be removed (to improve yields and manufacturing costs, and thus reducing the console price). Simple as that.

While every fixed function feature is going to be different removing the Xbox 360's tessellator wouldn't have allowed for another ALU or reduced the console price. I doubt Microsoft can even measure the yield reduction without going to a lot of decimal places.

Your post is correct in many areas, but I wanted to note that if a fixed function feature requires little enough hardware its production cost can effectively be hidden. Sections of the chip are synthesized and laid out separately and depending on how easy the section is to route and time utilization can be increased without negatively affecting area.

My main point is every extra gate in a chip isn't felt, but changes that are large enough to contribute percentage points to a section will start to affect area.

[sebbbi]

Originally Posted by 3dcgi

While every fixed function feature is going to be different removing the Xbox 360's tessellator wouldn't have allowed for another ALU or reduced the console price.

ATI already had the tessellator designed and integrated to their geometry processing unit. It was included in all of their DX9 chips. So the research and integration costs were already paid. The tessellator must have been a really small part of the chip, since ATI chose to include it in all their DX9 cards, even though it was pretty much never used (in PC games). Also ATI never did boost up other parts of their chips (triangle setup, etc) to cope up with the increased triangle counts made by the tessellator. It was just a cheap addition, not a huge feature that affected the whole GPU design.

However if you look at Fermi's architecture, it's evident that efficient tessellation required huge research costs and changes to chip layout. Nvidia split their rops (incl. edge setup) to four separate parallel units, and split their geometry processing units ("Polymorph Engine") to 16 parallel units. All of these fixed function units were previously located in a single unit. The new system required new communication paths between the geometry processing units (parallel execution hazards need to be solved), and lots of other changes. All these big architecture changes were implemented for tessellation. Tessellation hasn't still being used by more than a few games and benchmarks. Most Fermi cards are no longer in use when tessellation finally gets popular. So spending huge amount of transistors to tessellation wasn't really a good call for Fermi. Like I said earlier, fixed function hardware is a huge gamble. A link discussing all the changes in Fermi's geometry processing: http://www.anandtech.com/show/2918/2

[homerdog]

Removing the tessellator wouldn't necessarily allow them to add more ALUs even if it gave them the area to do it if you know what I mean. The chip already drew a lot of power.

[fellix]

The tessellator unit in both R600 and R700 architectures took no more than 2M transistors - a drop in the ocean of the whole budget. Xenos' implementation probably took even less than that, for a first generation product.

[Davros]

Originally Posted by sebbbi

ATI already had the tessellator designed and integrated to their geometry processing unit. It was included in all of their DX9 chips.

If your referring to Tru-Form I dont think thats true, the 8500 certainly had it but afaik it was done in the driver(aka software) on later cards then in later drivers abandoned.

[3dcgi]

Originally Posted by sebbbi

However if you look at Fermi's architecture, it's evident that efficient tessellation required huge research costs and changes to chip layout. Nvidia split their rops (incl. edge setup) to four separate parallel units, and split their geometry processing units ("Polymorph Engine") to 16 parallel units. All of these fixed function units were previously located in a single unit. The new system required new communication paths between the geometry processing units (parallel execution hazards need to be solved), and lots of other changes. All these big architecture changes were implemented for tessellation. Tessellation hasn't still being used by more than a few games and benchmarks. Most Fermi cards are no longer in use when tessellation finally gets popular. So spending huge amount of transistors to tessellation wasn't really a good call for Fermi. Like I said earlier, fixed function hardware is a huge gamble. A link discussing all the changes in Fermi's geometry processing: http://www.anandtech.com/show/2918/2

Tessellation can easily be made efficient with a single rasterizer and I agree Fermi did a good job with their multiple rasterizers. However, I bet they are happy with the area addition for it. It doesn't help much with games, but it helps tremendously in the workstation market. At AMD tessellation wasn't the reason we went with 2x prim rate for Cayman.

[rpg.314]

Originally Posted by sebbbi

The thing that annoys me most in fixed function hardware is that it limits my freedom. Fixed function hardware (and ratio of different FF hardware) is designed for the needs of an average game (usually last generation game, since hardware development takes time), and if your game is anything different, the hardware doesn't suit your needs that well. Games are different, and have different hardware requirements. Programmable hardware allows game developers to implement the game they want, not something that hardware manufacturer has planned for them. Creative freedom is important for good quality games. We need more different games, not hardware limitations that force us to do things in certain way.

I have been a graphics programmer since 3dfx era (Voodoo, Riva 128, TNT, etc are familiar for me). Ever since fixed function T&L came, graphics hardware has had major limitations compared to software graphics engines. You just had to cope with the limitations and invent creative hacks to get the required graphics features implemented. The time period when half of the cards supported EMBM (environment mapped bump mapping) and half of the cards supported DOT3 bumpmapping is something I really want to forget. Luckily DX8 was released, and we finally got shaders that allowed us to implement either one, and much much more. I have seen the golden age of fixed function graphics programming, and I don't want to go back there. Most of the things graphics programmers were doing back then was hacking their way around fixed function hardware limitations.

This era isn't the same as that era. Then you could only pack ff hw (which has amazing area efficiency) only for bits and pieces of the pipeline. Today you can do virtually entire pipeline in sw with reasonable perf. With more programmability it becomes easier all the time.

Let's say you take out 1 CU from Tahiti to put some ff hw for X in there. Your compute goes down by 3%. I am not advocating putting this at the expense of any flexibility one would desire as a programmer. What you can build today in 25M (50M?) transistors is nothing to sneeze at. And this marginal budget will increase all the time. Think about it, which algorithm is it that will fall off the usability cliff with 3% reduction in compute? No technique is affected adversely in any meaningful way. But there is one technique out there that is sped up 10x.

Now you could argue that the technique being implemented in ff should be well thought out. I totally agree. Tessellation took many goes to get it right (GS <-> xbox tessellator -> dx11). But there is more compute out there all the time and less and less of it will be usable, thanks to dark silicon. Even if your chip was wall to wall carpeted with compute, you wouldn't be able to use all of it all the time.

The way tessellation was implemented in DX11 API isn't that bad really. Domain shaders and hull shaders are written with the same language as all the other shaders and utilize the same programmable hardware. Only the part of the system that spawns new GPU work items is fixed function. We don't have yet programmable way to spawn work items on GPU, so this is understandable. But (in the future) when we get a proper way to do that, there might no longer be a need for separate hull and domain shaderes. Of course that is what I also want from the future.

Fixed function hardware bottlenecks are a real thing. When thinking about our last console project, I think that we were bottlenecked by triangle setup, texture sampling, vertex fetch, ALU, fill rate (rops), texture caches and BW . All in different stages of our scene rendering. Shadow map rendering for example was rop bound for near objects and triangle setup or vertex fetch bound for far away objects (depending on object type). Object rendering was texture sampling bound for some objects, texture cache bound for some (reflective), vertex fetch bound for some (high polygon far away) and ALU bound for some (very near objects with heavy shaders). Deferred lighting was ALU bound, and post processing was texture sampling bound. Most of the time during the frame we were bottlenecked by some fixed function unit. ALU was sitting there doing nothing during that time, and we were still heavily ALU bound during lighting. That's what happens when you have too many different bottlenecks (different fixed function units). We of course did some creative hacks to for example reduce vertex fetching bottlenecks (compress vertices, and burn some ALU to decompress) and to reduce texture fetching / BW bottlenecks (encoding/decoding), but optimizations like this were only a win for some cases, so the combination of shaders increased, and debugging and profiling time increased drastically. This is what you have to do in order to cope with the GPU fixed function bottlenecks. It takes lots of programming resources = makes games cost more to develop.

Consoles are so primitive that one has to dig deep to get anything useful done there. That kind of development is more exception than the norm. While it is true that your game was bound in different stages at different times, this whack a mole bottleneck is tempting to remove by going the mostly-sw route. But any reasonable analysis of bottlenecks in a mostly sw system vs whack a mole bottlenecks would reveal that a mostly sw route would have far worse bottlenecks in one place.

[Simon F]

Originally Posted by rpg.314

TTessellation took many goes to get it right (GS <-> xbox tessellator -> dx11). .

It's right?

[sebbbi]

Originally Posted by 3dcgi

At AMD tessellation wasn't the reason we went with 2x prim rate for Cayman.

And I agree that was a very good compromise for this generation of hardware. It removes bottlenecks of super high polygon mesh rendering, and improves tessellation performance, but didn't require huge overhaul of the architecture (or major commitment to rendering techniques that are not yet widely used).

Originally Posted by homerdog

Removing the tessellator wouldn't necessarily allow them to add more ALUs even if it gave them the area to do it if you know what I mean. The chip already drew a lot of power.

Current generation consoles didn't have any hardware for dynamic clock adjustments (turbo or throttling). The thermals had to be designed to handle full load on all units at the same time. Power consumed by all fixed function units in full load had to be surely taken into account in TDP design. Removing the tessellator for example might have not affected much, but removal of 4xMSAA hardware (including the EDRAM part of it) would surely have had big impact (on many things). But who would have though that popularity of MSAA would decrease so rapidly four/five years after the console launch. So I cannot critisize this decision. But in generally it shows that even big chunks of fixed function hardware can be left unused when rendering techniques evolve. Fixed function is not as future proof as programmable hardware.

Of course this is different for recent hardware that is designed to scale clocks up/down based on demand. All recent CPUs have turbo clocks, and GPUs are also getting similar features (Intel's GPUs have 3x clock scaling already). Mobile SoCs also have good clock scaling built in. This of course makes fixed function hardware a slighly smaller risk, because if it is unused, at least you can clock up the rest of the chip.

Originally Posted by rpg.314

Consoles are so primitive that one has to dig deep to get anything useful done there. That kind of development is more exception than the norm.

Console development isn't an "exception of the norm" for game programmers. Practically all AAA games are released on consoles, and most PC games are ports of console games. So game rendering pipelines need to be designed around console fixed function hardware bottlenecks. Things are moved around to minimize bottlenecks at every rendering stage (there are for example dozens of different deferred lighting/shading techniques just to combat different bottlenecks). These decisions also affect PC ports, as rewriting the whole rendering pipeline isn't something that most developers are willing to do lightly.

Originally Posted by rpg.314

While it is true that your game was bound in different stages at different times, this whack a mole bottleneck is tempting to remove by going the mostly-sw route. But any reasonable analysis of bottlenecks in a mostly sw system vs whack a mole bottlenecks would reveal that a mostly sw route would have far worse bottlenecks in one place.

But doesn't it feel even a little bit wrong also for a PC developer to have a whopping 2048 shader units (Tahiti) idling while you render your shadowmaps (bottlenecked by fixed function triangle setup or rops)? These 2048 shader units would surely be able to cruch a lot of triangle setup math. Or have 16 turbocharged geometry engines (Kepler) idling while you do deferred lighting and post processing?

I am not suggesting going fully sw route. Fixed function is fine for small repeated tasks. But I do not want to have more large scale fixed function units either. The goal must be more programmable/flexible pipeline in the future (not less).

[fellix]

At least, texture units and ROPs will remain dedicated HQ for the next few generations. They represent logic structures with very well determined functions/benefits, giving unbeatable performance, power and size ratio, no programmable logic array could even come close to. On the other hand, there's enough ALU throughput to complement and enhance those dedicated units, beyond their capabilities. Few examples: higher order mag filtering for the shadow maps, advanced post-AA on top of the hardware MS (TXAA), Elliptical Texture Filtering using the hardware AF as an input, etc.

[Kaotik]

Originally Posted by Davros

I disagree, with both amd and nv supporting up to 6 monitors on a single card now, I think we will see a lot of gamers go multimonitor

nVidia supports max of 4, not 6.

[Davros]

thats why I said up to

[rpg.314]

Originally Posted by Simon F

It's right?

Well it's used atleast. Much more than can be said for GS (as geometry amplifier) or xbox360.

[rpg.314]

Originally Posted by sebbbi

But doesn't it feel even a little bit wrong also for a PC developer to have a whopping 2048 shader units (Tahiti) idling while you render your shadowmaps (bottlenecked by fixed function triangle setup or rops)? These 2048 shader units would surely be able to cruch a lot of triangle setup math. Or have 16 turbocharged geometry engines (Kepler) idling while you do deferred lighting and post processing?

The ALU's aren't idle. They are probably processing another draw call at the time.
Besides, idle ALUs are better than saturated power hungry ALUs that turn out to be slower.

I am not suggesting going fully sw route. Fixed function is fine for small repeated tasks. But I do not want to have more large scale fixed function units either. The goal must be more programmable/flexible pipeline in the future (not less).

Ah, then we are talking degrees. I am in favor of more programmable pipeline as well. I just want to see more kinds of ff hw than is out there today.

[sebbbi]

Originally Posted by rpg.314

The ALU's aren't idle. They are probably processing another draw call at the time.

But that another draw call is using the same shader (kernel), and so it is bottlenecked by the same fixed function units. Console GPUs and many currently installed PC GPUs cannot run multiple kernels simultaneously (and the ability is very limited at best).

The ability to run multiple kernels in parallel was first introduced in Fermi GF-100 (http://www.anandtech.com/show/2849/5). It naturally requires that the kernels do not share (other than read only) resources (for example backbuffer), and it can only take draw calls (kernels) from the command list in the order they are submitted (*). This limits the usability a lot. Kepler's Hyper-Q improved this situation significantly. Kepler can fetch commands from up to 32 GPU command lists. This however doesn't help with graphics rendering, since current DX11 multithreading model is based on a single GPU command list (other threads just render to software command buffers that are submitted to one GPU command list, one after each other). This is one of the things that I hope is improved in DX12, since also AMDs heterogeneous system architecture (HSA) slides are also talking about running multiple contexts/kernels in parallel and feeding GPU by multiple command lists (GPU support will be there for both manufacturers). This is also a great way to reduce compute latency (user can set higher priority for command list that is used for submitting compute work).

(*) APIs do guarantee that your draw calls will be executed in the order they were submitted (result being identical to that order of execution). Since you usually have thousands of draw calls in your shadow map rendering, all tasks you can find to execute in parallel are using the same simple shader and are bottlenecked by same fixed function units.

In future DirectX versions you are likely able to submit alu heavy work to a separate command list and run it in parallel to shadow map rendering (GPU fetching from both comman lists, and doing context switching / shader unit allocation as it best determines). The easiest way to fill all the units all the time would be to process multiple frames simultaneously (added latency). For example you start a frame by rendering your shadow maps (vertex/rop/triangle heavy), and you are simultaneously doing deferred lighting and post processing for your previous frame (alu/tex/bw heavy). That would provide very good hardware utilization, but add half frame of extra latency. Or course if would also be more complex for the programmer to handle (manual load balancing between multiple shaders).

And it all depends also on how well the GPU can split it's resources. Some resources are tied to other resources. For example in Kepler, the geometry units are in the shader multiprocessors. If you need lots of shader multiprocessors for pixel crunching (lighting and post processing), you also occupy the geometry units, and thus they cannot be used simultaneously for another (geometry heavy) kernel.

[Jawed]

http://forums.create.msdn.com/forums/t/106060.aspx

There's even a question mark over whether D3D11.1 will run on W7 (and Vista, presumably). What are the chances of those OSs running D3D12? If that doesn't happen maybe we can just forget about D3D12 entirely.

How's OpenGL shaping up?... Is it going to catch up? Sorry for another de-rail subject.

[rpg.314]

Originally Posted by sebbbi

But that another draw call is using the same shader (kernel), and so it is bottlenecked by the same fixed function units. Console GPUs and many currently installed PC GPUs cannot run multiple kernels simultaneously (and the ability is very limited at best).

The ability to run multiple kernels in parallel was first introduced in Fermi GF-100 (http://www.anandtech.com/show/2849/5). It naturally requires that the kernels do not share (other than read only) resources (for example backbuffer), and it can only take draw calls (kernels) from the command list in the order they are submitted (*). This limits the usability a lot. Kepler's Hyper-Q improved this situation significantly. Kepler can fetch commands from up to 32 GPU command lists. This however doesn't help with graphics rendering, since current DX11 multithreading model is based on a single GPU command list (other threads just render to software command buffers that are submitted to one GPU command list, one after each other). This is one of the things that I hope is improved in DX12, since also AMDs heterogeneous system architecture (HSA) slides are also talking about running multiple contexts/kernels in parallel and feeding GPU by multiple command lists (GPU support will be there for both manufacturers). This is also a great way to reduce compute latency (user can set higher priority for command list that is used for submitting compute work).

I thought that single kernel limit was for compute only. Anyway, GCN/Cayman *look* like they have 2 separate command buffers. It's about time that we get multiple DX command queues though. This should definitely be in DX12.

[rpg.314]

Originally Posted by Jawed

http://forums.create.msdn.com/forums/t/106060.aspx

There's even a question mark over whether D3D11.1 will run on W7 (and Vista, presumably). What are the chances of those OSs running D3D12? If that doesn't happen maybe we can just forget about D3D12 entirely.

How's OpenGL shaping up?... Is it going to catch up? Sorry for another de-rail subject.

My expectation is that DX12 will come after xbox720. Not that it would differ much from DX11, considering the timelines. Win9 perhaps?

[eastmen]

what about daughter cards for more memory ? I'd love to see a board that would connect to future video cards. DDR 3 is extremely cheap and is pretty fast. Connecting say 16 to 32 gigs of ddr 3 1866 . Each channel should give 15 gigs of bandwidth. So dual channel should be 30gigs and quad would be 60 gigs . That be a nice boost for games and with 16-32 gigs it would fit most games inside of it.

I don't know if this would have to be included in the dx specs .

[fellix]

AMD: There Won’t be DirectX 12!

According to AMD’s Roy Taylor in an interview with Heise Online, DirectX 11 won’t have a successor. Here is the google-translated version of the interview in german where Roy says that DirectX 12 won’t see the light of day:


We will put together future Game Bundles top games. We believe this is the right way. But also for the industry, it is an important sign. Because the computer industry has benefited for many years from a continuous renewal of the DirectX interface. A new DirectX has time and again refreshed the industry, new graphics cards need more processors and more RAM. But there is no DirectX come 12th That’s it. As far as we know there are no plans for DirectX 12 If this is not correct and someone wants to correct me – wonderful.