Coder for life
Yesterday night I went to ageHa club in Tokyo to listen to Ferry Corsten.
I'm a big fan of Trance music.. it was great.. if only I weren't thinking all the time that I wanted to go back home and code !!
As I pretty much still develop on Windows, I've been using my Vaio laptop at home (not laptop from the company, they promised it once, but then took it back 8( ).
At home I only have a small desk and that's for the iMac. So when I use the Vaio it's on the kotatsu, with it's limited monitor and keyboard... not the best environment for developing (it's important to have a full size keyboard to write code !).
So, yesterday I decided to try installing Visual Studio on the iMac under VMWare Fusion. It works surprisingly well (I have 3GB of RAM). DX9 support doesn't seem to be there, but it's probably a setting or an upgrade. In any case recently for me it's either DirectX 10 (ewww) or software rendering (slooww).
Speaking of software rendering, I started with the idea of implementing a RenderMan state machine and borrow from RenderMan Shading Language. But the tendency is more towards Mental Ray.. which interestingly implements shaders as DLLs compiled in C/C++ (I've heard that Pixar itself does use all sort of languages to write shaders).
Writing shaders in C++ is one of my goals. HLSL/Cg kind of shaders are rather limiting, but for a good reason, those limits make it easier to write compilers that can parallelize operations. Still those limits are becoming unbearable and if shaders are written in C++, they can potentially run at the same level of a 3D engine on the same platform without having to create all those silly contractual interfaces like it happens with HLSL for example.
There will always be a problem with optimizing the interface between engine and modular shaders or any kind of module, but still, not having to worry about heavy state changes, buffering hardware display lists, etc etc, is going to make it easier to solve certain problems in different ways.
I see HLSL/Cg shaders like the (Macromedia) Flash of real-time 3D graphics: an excellent platform that can bring to great results with minimal effort, but a very limiting platform, eventually forcing a whole mindset to down the throat of an entire generation of graphics programmers.
It's important to be nonconformist sometimes !
woooooooo
- Davide's blog
- Login to post comments
Something to keep in mind is
Something to keep in mind is that shader hardware is not general purpose and HLSL/Cg were designed with that in mind....
If that wasnt the case then I dont really see a need in a 'shader' kind of concept. Your C/C++ rendering code merges with the rest of your graphics engine code, since it is running on the same processor anyway....
That was truer when shaders
That was truer when shaders for example didn't have conditional branches or loops.
Nowadays however, one can do pretty much anything with shaders. There is much talk and action towards GPGPU. NVidia itself is pushing that road, by releasing CUDA, buying AGEIA and Mental Images (with, I guess, the idea of accelerating offline rendering).
What's not well defined is how to rasterize polygons with GPGPUs. I think NVidia is possibly hoping to keep its lead in real-time by holding tight onto more real-time centered questions such as triangle setup acceleration, texture filtering, and by being very active with game developers.
Still.... Shader hardware
Still.... Shader hardware architecture and instruction set are very far from general purpose CPUs. Branching doesn't change much in my opinion since you still cant generate and manipulate data easily. You are mostly limited to processing vertex/pixel streams. In fact PS2's vector units were a lot closer to a CPU. So even though I agree with you that there is a growing trend to use the shader hardware for a more general processing we are still far from being able to write a whole game entirely on shader hardware.
Stream this !
I didn't mean to imply that it's a good idea to use shaders for everything. I think "streamizing" algorithms can help to make them more parallel and to work fast even on CPUs, but sometimes it's just crazy the way one has to shuffle buffers left and right.. not to mention the lack of proper debuggers.. debugging by means of colored pixels on screen can be a real nightmare !!
wooooooo
Hmmm I am not sure what you
Hmmm I am not sure what you mean by shuffling buffers, must be a directx10 specific issue.
Have you ever used PIX on the 360? Very good graphical debugging tool. There is also a windows version of PIX that works surprisingly well although not as stable and useful compared to the 360 version. On both versions you have asm level pixel/vertex shader debugging.
Furthermore you can even have source HLSL debugging with breakpoint etc... from within Visual Studio, but it is not so practical for pixel shaders since you have to run them in software emulation mode.
By shuffling I mean that
By shuffling I mean that complex operations have to be divided in multiple passes.
For image processing for example, it can be useful to write and read on the same buffer while it's being processed rather than being forced to think in terms of separate input and output buffers.
In so doing, one also uses then eventual data cache to it's best (do all the work while a cache line is hot, rather than relying on dumb non-cached writes).
On the other side, it's possible that it's not so easy to parallelize an algorithm like that because then multiple threads have to worry about sharing common read-write memory access if they don't work aligned on cache-lines and especially if the algorithm itself requires the data chunk boundaries to overlap (when the end of a convolution data chunk is also the start of next chunk and those two chunks are being processed by different threads).
It's also true that some necessities when working with (real-time) shaders can be actual good performance practices when working with less limited architectures.
For example, when doing a Gaussian blur, it's a lot faster if one does rows and columns in two separate passes. In DSP terms this is called "Convolution by Separability", and it's definitely a good thing 8) ..you don't have to do it with a CPU, but it's definitely better to do it.
Ah I see, on xbox360 you
Ah I see, on xbox360 you have the MEMEXPORT function.
http://www.beyond3d.com/content/articles/4/10
But I think that feature is unique to the 360 only.
ohhh.. interesting ! ..one
ohhh.. interesting ! ..one more reason why coding on PC sucks: somehow DMA was never really in the hands of the user-application programmers (as opposed to drivers programmers).