Jump to content
  • Advertisement
  • entries
    422
  • comments
    1540
  • views
    490121

Thoughts on the August 2006 DirectX SDK

Sign in to follow this  
jollyjeffers

299 views

I finally made the jump from the December 2005 SDK to the latest-n-greatest August 2006 SDK. I still can't do anything with the D3D10 stuff ([bawling]) but I wanted to get myself a piece of the PIX goodness. Seems like PIX is making some leaps-and-bounds right now which can't be a bad thing!

  • They've removed the DX control panel applet from the control panel and made it a regular tool inside the SDK. I dont understand the logic behind this - it doesn't seem to have changed, so why "fix" something that aint broke?

  • This MS blog indicates Vista ships with OpenGL 1.4, yet the new "Graphics API's in Windows Vista" whitepaper (which is well worth a read, even if its got a lot of marketing spin) says:
    Quote:
    Windows Vista provides the same support as Windows XP for OpenGL, which allows video card manufactures to provide an installable client driver (ICD) for OpenGL that provides hardware-accelerated support; note that newer versions of such ICDs are required to fully support Windows Vista. If no ICD is installed, the system will fall back to the OpenGL v1.1 software layer in most cases.
    Okay, so my understanding of OpenGL is limited, but that doesn't match up, does it?

  • cardcaps.xls, updated April '06, now includes X1800. Means it now covers every major chipset on the block which is a good thing.

  • The MotionBlur10 demo (which I can only see via a movie) is still a bit too unclear. Nothing new from the Dec'05 version though. I suppose subtlety is important, but the demo could be improved (e.g. a "slow-mo" version) so us developers can actually see whats going on.


    PIX for Windows

    This is the part I'm most interested in. I've spent most of the morning digging around in the new features, but I'm sure I've probably missed a few things. I definitely need to look into the 'Pixel History' feature a bit more.

    First annoyance was that my WaterRenderer demo (see previous journal entry) explodes on impact with PIX. Works fine in all other environments (from explorer, from the IDE) and modes (debug/retail/release modes). Run it from PIX and its a quick and firey death of access violations and hard crashes. This is especially annoying as I've broken said project and I actually need to use PIX to help me debug it. Guess I need to knock up a repro for MS.

    Second annoyance is that the UI hasn't been improved. I asked for this to be done a while back but I suppose it wasn't deemed important. Now its just annoying me. For a tool like PIX that often has incomprehensibly huge amounts of information on display a good, intuitive and responsive UI is absolutely essential.

    On a number of occasions I "lost" information because I accidentally hid windows. On all occasions I spent noticeable time trying to juggle the windows around so I could see as much of what I wanted on the screen at any one time. I'm sure its a bug, but on a couple of occasions I also managed to disappear entire windows and had to restart PIX to get them back again.

    I figure that PIX is a perfect example of why a high-res desktop is useful. It just looks crowded and cramped on my 15" 1024x768 display. Maybe the developers are testing it at a high resolution, if so then I think they need to do some low-res testing [smile]

    In the past I've quickly dropped tools and gone back to doing things manually when they get in my way. I get the feeling that I'm spending as much time "working" the tool as I am actually "using" it.

    Bottom line - it needs some serious work. I dont have an answer to it myself as organising that much information is no simple task.



    The mesh view mode is pretty damned cool. Clicking on the "Post VS" tab allows you to access the VS shader debugger. Clicking on a vertex highlights it in yellow along with the other two vertices (for the current primitive) in red. You can also see it highlighting the vertices in each of the 3 images across the top. Very cool.

    Having the index buffer data was pretty useful for me to verify that my cache-optimization algorithm generated the intended pattern.

    Although, one downside is that you cant scale/resize the 3 images across the top. You can just see it in the 'Viewport' image, but those shots are actually wireframe (as they should be), but for a dense mesh like mine it becomes just a constant colour. Resizing the image should solve that.



    The vertex shader debugger is pretty cool. If you compile with D3DXSHADER_DEBUG|D3DXSHADER_SKIPOPTIMIZATION you get comments tagging the assembly so you can see what its doing. However I find it to be a little unclear quite where the comments are applicable:



    I'm pretty sure that the commented line indicates the line where the final result is computed/stored. Thus the first 6 highlighted lines are all for the // ComputeOrenNayar::A<0> part. But its not clear without a bit of head-scratching.

    A little effort on PIX's behalf could highlight/outline groups of instructions and make it a whole lot more intuitive.

    The shader debuggers are in need of some cosmetic work - the regular "View * Shader" links have syntax highlighting and DONT wrap text at EOL. The shader debugger could really do with having these things enabled - looking at huge lists of text is so much easier on my eyes when theres a bit of colour [smile]

    Intellisense. This is needed in the debugger - it'd make it SO much better. Just look at debugging normal code in VStudio - you step through code, either using the "watch" window (which PIX also has, although nowhere near as good) and hover the mouse over declarations, variables and so on - the tooltip provides the necessary information. Whilst it was often broken the VStudio Shader Debugger did this in a limited fashion.

    I'd like to see the contents of a register when I hover my mouse over it. I want an explanation/name of an assembly instruction when I hovever over it - straight from the docs, a tooltip with "Computes the reciprocal of the source scalar" when hovering over the rcp instruction would be perfect.

    Pixel History looks good, but the sample I was using (my vertex cache demo) doesn't use complex pixel shaders so I couldn't test this fully. I have some very clear ideas about what I want from this feature, so hopefully I wont be disappointed. If PIX hadn't exploded on my WaterRenderer demo then I'd of had a chance to try this feature - my current problem is with a broken PS effect, so it'd be nice to dig in and find out why [headshake]

    Conclusion: Without a doubt an excellent tool, but still too rough around the edges.

    Maybe its just me, but I get real cranky and am quick to anger when a tool becomes a chore to use. Given that debugging using PIX is already very much a 2-phase and slow process, having to do battle with an unintuitive UI only adds to the frustration.

    In the hope that 'the powers that be' read this, my wishlist:

    1. Improve the UI. Make it easier for me to arrange the information on the screen, stop the windows doing stupid things like jumping around, hiding and so on... Why can't I close views?

    2. Mesh view. Allow us to resize/scale the three images across the top. Maybe even a simple case of double-clicking opens a larger view in a new window.

    3. Improve the shader debugger's use of compiler-added debug information. I'd like to see a box/line drawn next to related groups of instructions.

    4. Get rid of the line-wrapping in the shader debuggers FX/HLSL viewer. The other modes for viewing shader code dont do this, so why have it here?

    5. Syntax highlighting for both ASM and HLSL code in the shader debugger

    6. Intellisense for shader debugging; tell me what assembly instructions do and show me the contents of registers when I hover over them.

    7. Add a "run to cursor" debugging. For a long shader clicking on the "step" button 10-20 times to get to a section I want is tedious.

    8. Have an option to force _DEBUG and/or _SKIPOPTIMIZATION flags on shaders. Whilst it isn't hard, I'm not a fan of modifying my code just to suit the debugger.
  • Sign in to follow this  


    8 Comments


    Recommended Comments

    re:OpenGL stuff

    You're right, that doesn't match up at all, I suspect it was a typo/someones brain being off, as everything I've seen indicated 1.4 support and not 1.1.

    Not that it matters as really as I dare say the majority of people will install drivers from their gfx card vendor which means they will have OGL2.0+ on there (most likely anyways) and with plans for a new sdk and dll/lib pair independant of MS for OGL3.0 it matters even less [smile]

    Share this comment


    Link to comment
    Doesn't Vista require that the user have some insane video card to begin with? Even today the only time you're going to see OGL 1.1 is if someone has a dinosaur or hasn't installed the proper drivers.

    And I really need to learn shaders so I know what the hell you're talking about [sad].

    Share this comment


    Link to comment
    Quote:
    You're right, that doesn't match up at all, I suspect it was a typo/someones brain being off
    Yeah, that was my first thought but I don't know much about OpenGL so thought it best to check first [smile]

    Quote:
    Doesn't Vista require that the user have some insane video card to begin with?
    Nope, you need a DX9-level SM2 card (basically anything newer than a GeForce FX or Radeon 9500) to get AERO Glass. To get Direct3D 10 goodness you'll need a D3D10 card (none currently available), but the OS itself has no requirement for this.

    Quote:
    And I really need to learn shaders so I know what the hell you're talking about
    Yes, yes you do need to learn shaders. I survived with FF for a long time, but now I'm up and running with shaders (didn't take long at all) I'm never ever going back [grin]

    Cheers,
    Jack

    Share this comment


    Link to comment
    Quote:
    and with plans for a new sdk and dll/lib pair independant of MS for OGL3.0 it matters even less

    Christ, finally. "Let's bank our entire fucking business on Microsoft, because they surely haven't ever done anything unethical or uncompetitive to gain market share." [rolleyes]

    Share this comment


    Link to comment
    Quote:
    They've removed the DX control panel applet from the control panel and made it a regular tool inside the SDK. I dont understand the logic behind this - it doesn't seem to have changed, so why "fix" something that aint broke?


    I posted the same question on David's blog and got the following reply from a fellow visitor:

    Quote:
    This is likely due to least-user-privilege accounts on Vista. Control panels (CPLs) have limited ability to elevate privileges on Vista while .exes have more facility.

    This also makes the SDKs (closer to) side-by-side since the CPL was one of the few remaining pieces shared between revisions of the SDK.


    Sounds credible [wink]

    Share this comment


    Link to comment
    Yeah, I suppose that explanation for the CPL part makes sense. I think I read that comment in David's blog shortly after making my entry here [oh]

    Jack

    Share this comment


    Link to comment
    Guest Anonymous Poster

    Posted

    Re: 7. Add a "run to cursor" debugging. For a long shader clicking on the "step" button 10-20 times to get to a section I want is tedious.

    Luckily, you can do this with PIX! You can set breakpoints by clicking in the left margin of the Disassembly pane; then just click Run.

    Ian.

    Share this comment


    Link to comment
    Quote:
    Original post by Anonymous Poster
    Re: 7. Add a "run to cursor" debugging. For a long shader clicking on the "step" button 10-20 times to get to a section I want is tedious.

    Luckily, you can do this with PIX! You can set breakpoints by clicking in the left margin of the Disassembly pane; then just click Run.
    Interesting - must have missed that feature. Thanks for pointing it out, I'll be sure to check it out when I get a chance.

    Cheers,
    Jack

    Share this comment


    Link to comment

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now
    • Advertisement
    ×

    Important Information

    By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

    We are the game development community.

    Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

    Sign me up!