A very short post in the sequel of my previous post "Advanced HLSL using closures and function pointers", there is again a little neat trick by using the "class" keyword in HLSL: It is possible to use a class to regroup a set of parameters (shader resources as well as constant buffers) and their associate methods, into what is called a compound parameter. This feature of the language is absolutely not documented, I discovered the name "compound parameter" while trying to hack this technique, as the HLSL compiler was complaining about a restriction about this "compound parameter". So at least, It seems to be implemented up to the point that it is quite usable. Let's see how we can use this...
Update your bookmarks! This blog is now hosted on http://xoofx.com/blog
Showing posts with label shader. Show all posts
Showing posts with label shader. Show all posts
Saturday, April 20, 2013
Thursday, November 24, 2011
Advanced HLSL using closures and function pointers
Shader languages like HLSL, Cg or GLSL are nowadays driving the most powerful processors in the world, but if you are developing with them, you may have been already a little bit frustrated by one of their expressiveness limitations: the common problem of abstraction and code reuse. In order to overcome this problem, solutions so far were mostly using a glue combination of #define/#include preprocessors directives in order to generate combinations of code, permutation of shaders, so called UberShaders. Recently, this problem has been addressed, for HLSL (new in Direct3D11), by providing the concept of Dynamic Linking, and for GLSL, the concept of SubRoutines, For Direct3D11, the new mechanism has been only available for Shader Model 5.0, meaning that even if this could greatly simplified the problem of abstraction, It is unfortunately only available for Direct3D11 class graphics card, which is of course a huge limitation...
But, here is the good news: While the classic usage of dynamic linking is not really possible from earlier version (like SM4.0 or SM3.0), I have found an interesting hack to bring some kind of closures and functions pointers to HLSL(!). This solution doesn't involve any kind of preprocessing directive and is able to work with SM3.0 and SM4.0, so It might be interesting for folks like me that like to abstract and reuse the code as often as possible! But let's see how It can be achieved...
But, here is the good news: While the classic usage of dynamic linking is not really possible from earlier version (like SM4.0 or SM3.0), I have found an interesting hack to bring some kind of closures and functions pointers to HLSL(!). This solution doesn't involve any kind of preprocessing directive and is able to work with SM3.0 and SM4.0, so It might be interesting for folks like me that like to abstract and reuse the code as often as possible! But let's see how It can be achieved...
Thursday, August 26, 2010
Making of Ergon 4K PC Intro
What is Ergon? It's a small 4k intro (meaning 4096 byte executable) that was released at the 2010 Breakpoint demoparty (if you can't run it on your hardware, you can still watch it on youtube), which surprisingly was able to finish to the 3rd place! I did the coding, design and worked also on the music with my friend ulrick.
That was a great experience even if I didn't expect to work on this production at the beginning of the year... but at the end of January, when BP2010 was announced and supposed to be the last one, I was motivated to go there, and why not, release a 4k intro! One month and a half later, the demo was almost ready... wow, 3 weeks before the party, first time to finish something so ahead an event! But yep, I was able to work on it on part time during the week (and the night of course)... But when I started on it, I had no idea where this project would bring me to... or even what kind of 3D API I had to start from doing this intro!
Saturday, February 13, 2010
Coding a 4k intro for Breakpoint 2010
I'm going to be quite busy here until the demoparty Breakpoint 2010, as I want to release a small 4k intro for this great event! I didn't plan anything few weeks ago and was slowly working on d3d10/d3d11, working on some effects for a 16k/64k intro to release later this year... but BP2010 is supposed to be the last one and I don't want to miss this experience, first time to go there... and probably last time, so I have decided to go to this party and try to contribute to it, yep!
I have started to work with d3d10, as i wanted to add some direct2D nice layout text over 2-3 raymarching scenes... but I have found that direct2D is bit too costly for a 4k, specially if you want to avoid the basic white logo... so I have to switch back to a plain d3d9 and forget about some cool text. I will use this direct2D technique for a bigger intro. Due to my lack of investment in all the d3d apis until now, I had to manage the API from the ground up... and it took me a while... To facilitate the d3d10/d3d11 coding experience, I have developed a lightweight c++ wrapper around d3d10/11 APIs, almost exactly in the same way (naming conventions,enums) SlimDx has done the job, and I'm really happy with it. The d3d10/d3d11 API is very clean but due to some verbose API contraints (ugly enums mixed sometimes with some #define, HRESULT to check from every function return, a famous windows programming philosophy), It's really worth to wrap this API around something that transparently hide all those things, rename and rearrange enum/methods/interface. Currently, It's working great with this SlimDx's like wrapper, much easier to program, much easier to read, and It does generate almost exactly the same code than a straight d3d10/d3d11 code, with the capability to remove the HRESULT check and so on... I will probably release this wrapper ( a single .h with a bunch of inline methods) around codeplex later this year, as it should probably help people like me that prefer a syntax much more closer to the C# coding experience than c/c++.
During my small d3d11 incursion, I have also discovered that the DirectX Effect framework (fx syntax files, with techniques, pass) is no longer available as part of the D3DX runtime! Yep, you need to go to the Utility directory in the DirectX SDK to find that you can compile this framework yourself... It means that for all intros, you can forget about the DirectX Effect framework and program a much lighter Effect framework. One good thing about this change is that I had to better understand the d3d10 philosophy with the constant buffers access and so on... In fact, It's much easier to work directly with constant buffer, and surprisingly, It gives a smaller code. As soon as I'm done with the 4k intro for BP2010, I will publish a small post about this along the SlimDx like wrapper.
Last thing is that I didn't have time to finish my softsynth, because I was more targeting a 16k/64k, with a more complex synth... so we should go with the great 4klang gopher's synth... but I have two problems with it : 1) ulrick (my old friend, main FRequency musician) is unable to use it under Renoise. It burns its notebook's CPU and we don't know why, as it's a pretty standard core 2 duo intel processor... we did check lost of 4klang/renoise/system parameters without any success. 2) 4klang is great, but, the total code is often close to 900 bytes... I know that some of the top's 4k softsynth are around 500 to 700 bytes, so I'm not completely sure that I will use 4klang. The other idea is to take part of the work I did already for the bigger synth (that is developped in assembler x86), and try to plumb it into a fixed pipeline (and not a stackbased as 4klang)... I'm not sure, but I suspect that I could save a substantial amount of bytes... but still, not sure, and I need to check it... but It's going to be really hard to make it on time for BP... so we'll see...
Currently, I have only coded one scene for the 4k intro, I'm quite happy with it... but that doesn't make a full intro! I need to add at least 3 scenes, work on the transitions, overall design, synch with synth & so on... even for a 4k, that's a lots of work, moreover when you consider that this is my first prod on my own (I mean, first prod for the PC, after the 3 prods i released 20 years ago on Amiga! ;) ) but It's possible in less than 2 month to do it, so I'll try to do my best!
I have started to work with d3d10, as i wanted to add some direct2D nice layout text over 2-3 raymarching scenes... but I have found that direct2D is bit too costly for a 4k, specially if you want to avoid the basic white logo... so I have to switch back to a plain d3d9 and forget about some cool text. I will use this direct2D technique for a bigger intro. Due to my lack of investment in all the d3d apis until now, I had to manage the API from the ground up... and it took me a while... To facilitate the d3d10/d3d11 coding experience, I have developed a lightweight c++ wrapper around d3d10/11 APIs, almost exactly in the same way (naming conventions,enums) SlimDx has done the job, and I'm really happy with it. The d3d10/d3d11 API is very clean but due to some verbose API contraints (ugly enums mixed sometimes with some #define, HRESULT to check from every function return, a famous windows programming philosophy), It's really worth to wrap this API around something that transparently hide all those things, rename and rearrange enum/methods/interface. Currently, It's working great with this SlimDx's like wrapper, much easier to program, much easier to read, and It does generate almost exactly the same code than a straight d3d10/d3d11 code, with the capability to remove the HRESULT check and so on... I will probably release this wrapper ( a single .h with a bunch of inline methods) around codeplex later this year, as it should probably help people like me that prefer a syntax much more closer to the C# coding experience than c/c++.
During my small d3d11 incursion, I have also discovered that the DirectX Effect framework (fx syntax files, with techniques, pass) is no longer available as part of the D3DX runtime! Yep, you need to go to the Utility directory in the DirectX SDK to find that you can compile this framework yourself... It means that for all intros, you can forget about the DirectX Effect framework and program a much lighter Effect framework. One good thing about this change is that I had to better understand the d3d10 philosophy with the constant buffers access and so on... In fact, It's much easier to work directly with constant buffer, and surprisingly, It gives a smaller code. As soon as I'm done with the 4k intro for BP2010, I will publish a small post about this along the SlimDx like wrapper.
Last thing is that I didn't have time to finish my softsynth, because I was more targeting a 16k/64k, with a more complex synth... so we should go with the great 4klang gopher's synth... but I have two problems with it : 1) ulrick (my old friend, main FRequency musician) is unable to use it under Renoise. It burns its notebook's CPU and we don't know why, as it's a pretty standard core 2 duo intel processor... we did check lost of 4klang/renoise/system parameters without any success. 2) 4klang is great, but, the total code is often close to 900 bytes... I know that some of the top's 4k softsynth are around 500 to 700 bytes, so I'm not completely sure that I will use 4klang. The other idea is to take part of the work I did already for the bigger synth (that is developped in assembler x86), and try to plumb it into a fixed pipeline (and not a stackbased as 4klang)... I'm not sure, but I suspect that I could save a substantial amount of bytes... but still, not sure, and I need to check it... but It's going to be really hard to make it on time for BP... so we'll see...
Currently, I have only coded one scene for the 4k intro, I'm quite happy with it... but that doesn't make a full intro! I need to add at least 3 scenes, work on the transitions, overall design, synch with synth & so on... even for a 4k, that's a lots of work, moreover when you consider that this is my first prod on my own (I mean, first prod for the PC, after the 3 prods i released 20 years ago on Amiga! ;) ) but It's possible in less than 2 month to do it, so I'll try to do my best!
Friday, January 8, 2010
Building .fx hlsl files with a Custom Build Rule under Visual Studio 2008
It's sometimes convenient to be able to compile directly a .fx file under a VS C++ project. NShader provides a nice way to highlight your code, but it's not able (yet, not sure I will update it up to this feature) to compile anything or to display syntax errors.
Hopefully, there is a simple workaround, avoiding to develop your own custom building task : using a custom build rule. Unfortunately, I was able to find one a while ago on Internet, but I lost it, and if I remember, it was lacking some features (like showing all available profiles)... So I decided yesterday to implement my own building rules files, leveraging on the existing .asm rules files that is shipped with Visual Studio, and It was surprisingly easy to write it.
To add this custom building rules to VS, follow these instructions:
Hopefully, there is a simple workaround, avoiding to develop your own custom building task : using a custom build rule. Unfortunately, I was able to find one a while ago on Internet, but I lost it, and if I remember, it was lacking some features (like showing all available profiles)... So I decided yesterday to implement my own building rules files, leveraging on the existing .asm rules files that is shipped with Visual Studio, and It was surprisingly easy to write it.
To add this custom building rules to VS, follow these instructions:
Subscribe to:
Posts (Atom)