As each thread is no longer treated as a pixel, so the association with geometry is lost (unless specifically passed in a data structure). This hardware will need to be a little more flexible than it currently is as when it runs CS code it will have to support random reads and writes and irregular arrays (rather than simple streams or fixed size 2D arrays), multiple outputs, direct invocation of individual or groups of threads as per the programmer's needs, 32k of shared register space and thread group management, atomic instructions, synchronization constructs, and the ability to perform unordered IO operations.Īt the same time, the CS loses some features as well. The Compute Shader, like the other fully programmable stages of the DX10 and DX11 pipeline, will share a single set of physical resources (shader processors). Developers have the option to pass data structures over to the Compute Shader and run more general purpose algorithms on them. Although we can shoehorn general purpose algorithms into a pixel shader program, we don't have the freedom to use data structures like trees, sharing data between pixels (and thus threads) is difficult and costly, and we have to go through the motions of drawing triangles and mapping solutions onto this.Įnter DirectX11 and the CS. In other pipeline stages, we see limitations imposed that are designed to speed up execution that get in the way of general purpose code. We see added flexibility in both the type of operations that can be preformed on data and the type of data that can be operated on. This addition to the pipeline steps further from a render-centric API and enables more general purpose algorithms. Many developers are excited about the added flexibility of the Compute Shader (also referred to as the CS). Going Deeper: The DX11 Compute Shader and OpenCL/OpenGL
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |