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?
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:
- 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?
- 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.
- 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.
- 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?
- Syntax highlighting for both ASM and HLSL code in the shader debugger
- Intellisense for shader debugging; tell me what assembly instructions do and show me the contents of registers when I hover over them.
- 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.
- 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.
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]