When are shaders going to be replaced?
- Thread starter K.I.L.E.R
- Start date
Luminescent
Veteran
Shaders are just a common term for descriptive 3D object (primitive, vertex, fragment) programs. Shaders will probably not be replaced by anything, anytime soon, but raytracing algorithms may at one point. These are still programs, but are a departure from the standard form of scanline rendering.
The current trend is to replace low-level shaders (the assembly-like language) with high-level shaders (the C-like languages). Since programming languages like C have survived through several decennia, I doubt if shaders will be replaced any time soon. On the contrary, I believe that they will get more versatile, and a standard high-level shader language will be created. If DirectX 10 and OpenGL 2.0, ATI and NVIDIA can make such an agreement, it would definitely be better for game programmers. Although I'm probably very naive at that point.
In the far future, I expect GPUs to face the same problems as CPUs. They are already bumping into the same limits for memory throughput, frequency, die size, heat dissipation, etc. So eventually the technology used in GPUs and CPUs will be nearly the same. Especially with very programmable GPUs they will totally resemble each other. So it is possible that CPUs with 8 times the number of execution units, 16-fold Hyper-Threading and 4 times higher clock speed on a .065 micron process perform almost equally to the GPU. It also does not require AGP transfers and all memory can be written and read without limitations. Already today we see the gap between software and hardware T&L closing slightly.
Or look at it this way: current high-end GPUs spend lots of silicon on features that are rarely used. To make better use of the number of available transistors, architectural changes will have to be made. We already see this happening, for example when drivers implement fixed-function operations using the shader pipeline. I can already see how this evolves into a Pentium 4 HT-like architecture, only with more execution units and running vertex shader and pixel shader threads, and with of course it's own microcode.
Hmm, now that I think of it, a Pentium 4's microcode can be reprogrammed...
In the far future, I expect GPUs to face the same problems as CPUs. They are already bumping into the same limits for memory throughput, frequency, die size, heat dissipation, etc. So eventually the technology used in GPUs and CPUs will be nearly the same. Especially with very programmable GPUs they will totally resemble each other. So it is possible that CPUs with 8 times the number of execution units, 16-fold Hyper-Threading and 4 times higher clock speed on a .065 micron process perform almost equally to the GPU. It also does not require AGP transfers and all memory can be written and read without limitations. Already today we see the gap between software and hardware T&L closing slightly.
Or look at it this way: current high-end GPUs spend lots of silicon on features that are rarely used. To make better use of the number of available transistors, architectural changes will have to be made. We already see this happening, for example when drivers implement fixed-function operations using the shader pipeline. I can already see how this evolves into a Pentium 4 HT-like architecture, only with more execution units and running vertex shader and pixel shader threads, and with of course it's own microcode.
Hmm, now that I think of it, a Pentium 4's microcode can be reprogrammed...
I believe should we see big evolutions in the next ten years, I'd bet on the following ones:
- A Programmable Primitive Processor ( heck, it's already in the NV40 )
- Dynamic Allocation. VS / PS programs share, for the most part at least, the same calculation units ( which would thus obviously be FP32 )
- Even more flexibility on the shading level, going beyond the idea of calling it "vertex" or "pixel" shading. That means EVERYTHING is programmable ( beside a few things, but then they'd still be instructions ) - and that you don't even see a distinction between pixel, triangle and vertex. It's just information. If you wanted, you could completely bypass triangles and have a vertex shader write to five calculated positions. Something you'd traditionally call a "pixel" shader would be able to create other pixels. You might even be able to create vertices, but then it'd get real icky, so I doubt that's ever gonna happen.
Of course, that last point is very future-looking, and even 10 years might be too optimistic for it. But I believe it will happen, evantually.
Then, what will differentiate CPUs from GPUs?
- Massive parallelism. The same code is used for a lot of stuff, and may even be stored in memory to be reused later ( heck, the NV3x already stores pixel programs in memory to not have to resend them through AGP )
- Always works on Vec4s or Vec3s/Scalars
- Dedicated things like triangle setup/interpolation/... being done VERY fast indeed.
- Native support for graphics-oriented intructions
- A lot less cache than on a CPU.
Uttar
- A Programmable Primitive Processor ( heck, it's already in the NV40
)- Dynamic Allocation. VS / PS programs share, for the most part at least, the same calculation units ( which would thus obviously be FP32 )
- Even more flexibility on the shading level, going beyond the idea of calling it "vertex" or "pixel" shading. That means EVERYTHING is programmable ( beside a few things, but then they'd still be instructions ) - and that you don't even see a distinction between pixel, triangle and vertex. It's just information. If you wanted, you could completely bypass triangles and have a vertex shader write to five calculated positions. Something you'd traditionally call a "pixel" shader would be able to create other pixels. You might even be able to create vertices, but then it'd get real icky, so I doubt that's ever gonna happen.
Of course, that last point is very future-looking, and even 10 years might be too optimistic for it. But I believe it will happen, evantually.
Then, what will differentiate CPUs from GPUs?
- Massive parallelism. The same code is used for a lot of stuff, and may even be stored in memory to be reused later ( heck, the NV3x already stores pixel programs in memory to not have to resend them through AGP )
- Always works on Vec4s or Vec3s/Scalars
- Dedicated things like triangle setup/interpolation/... being done VERY fast indeed.
- Native support for graphics-oriented intructions
- A lot less cache than on a CPU.
Uttar
Luminescent
Veteran
Actually, R3xx can work on Vec4+scalars.
I could be very wrong, but I do think they will be closer together:Uttar said:
- With Hyper-Threading technology you can increase parallelism on the CPU a lot. The limit is where the cost of 'distributing' execution ports over the instructions is higher than the execution time itself. But this can be prevented with placing multiple cores on one die and load-balancing.
- Integer arithmetic is still faster, and in many situations it has sufficient precision. For example, texture coordinates after the corresponder function don't have to be in floating-point format and 32-bit integer is in this situation more precise than 32-bit floating-point.
- Could you tell me precisely what "graphics-oriented" instructions are? It's not imaginary that people will use totally different algorithms for which some instructions could be worthless. Using more general instructions like with a Pentium 4 you can do anything. The idea of changing microcode spooks in my head...
- On a processor with centralized execution units running multiple threads it is essential to have big caches with high set-associativety (to keep other threads from erazing needed cache lines). With pre-fetching techniques you can lower this need but benchmarks still show performance gains from bigger caches.
Of course I'm thinking very far ahead when polygon rasterization is outdated...
Similar threads
