Page 2 of 2 FirstFirst 12
Results 11 to 17 of 17

Thread: Inventing on Principle

  1. #11
    Quote Originally Posted by WILL View Post
    How restrictive those would need to be and what to restrict and what is safe could be a cause for debate.
    Well the other risk is that if you end up having to manually qualify and safeguard what is risky & what isn't, you could just as well end up spending more time doing that than designing, or end up with design tools that are too restrictive/specific to be more useful than a "classic" IDE or game level editor...

    I'm thinking that this approach can only blossom if all the hard, low-level aspects are taken care of already.

    Quote Originally Posted by WILL View Post
    But perhaps we are taking the Inventing on Principle concept too literally by going right down to API level...
    I'm not sure: if you're using this approach to design a shader f.i., you'll have a few sample scenes ready, and will want to preview/tweak the shader interactively.

    At that point, either you're only tweaking the shader parameters (and doing no better than what already exists), or you're editing the shader code itself, and seeing the results interactively, but that assumes your hardware can handle buggy shaders without crashing or locking up.

    Even without interactivity, there is nothing more annoying when you're trying to tweak a shader than having the driver fold up and having to reboot. That has happened to me for all 3D APIs at some point or another, and it's not just frustrating from a design POV, it's also frustrating from a deployment POV, because it makes you wonder "ok, if this shader can crash my PC, what will it do on users machines with their outdated drivers?"

  2. #12
    Co-Founder / PGD Elder WILL's Avatar
    Join Date
    Apr 2003
    Location
    Canada
    Posts
    6,107
    Blog Entries
    25
    Well you could write a middle-layer for graphics that kept you from messing with breakable API code. Then just stick to that layer and you won't crash during development. You'd lose some low level control, but you do gain that added feel towards the creative hands in your code real-time effect that is what you are going for. I personally think that that's the only way. Until the hardware starts putting in safeties that will prevent hurting the drivers.
    Jason McMillen
    Pascal Game Development
    Co-Founder





  3. #13
    Quote Originally Posted by Eric View Post
    Even without interactivity, there is nothing more annoying when you're trying to tweak a shader than having the driver fold up and having to reboot. That has happened to me for all 3D APIs at some point or another, and it's not just frustrating from a design POV, it's also frustrating from a deployment POV, because it makes you wonder "ok, if this shader can crash my PC, what will it do on users machines with their outdated drivers?"
    Would you please share the shader code that managed to crash your PC? What operating system and API did you use?

  4. #14
    Quote Originally Posted by WILL View Post
    Well you could write a middle-layer for graphics that kept you from messing with breakable API code.
    Well, that's what ANGLE is trying to achieve (http://code.google.com/p/angleproject/ and http://blog.chromium.org/2010/03/int...e-project.html), but they're not quite there just yet, and they still have to exclude a variety of graphics cards and hardware drivers for stability reasons.

    I don't remember if FireFox also uses ANGLE, but I've read that both Chrome & FireFox perform extra checks on the shaders to try and detect errors the HLSL compiler and drivers don't handle very well (like http://www.gamedev.net/topic/579554-...-crash-in-dx9/).

    But anyway, I'm hoping the push for stable 3D graphics in web apps will ensure that stability will happen, from the hardware vendors down, ANGLE & other middle-layers will (and already) have trouble keeping up with all the new hardware and driver revisions.

    Would you please share the shader code that managed to crash your PC? What operating system and API did you use?
    It was definitely nVidia, and crashing with either Cg & HLSL, I don't have the code available anymore, but it might have been a similar issue to the DX9 one I linked above, ie. an error in the shader code that wasn't reported correctly.

  5. #15
    Quote Originally Posted by Eric View Post
    It was definitely nVidia, and crashing with either Cg & HLSL, I don't have the code available anymore, but it might have been a similar issue to the DX9 one I linked above, ie. an error in the shader code that wasn't reported correctly.
    It is weird since in 6 years working with shaders (both in FX Composer and directly) I've never had a video driver crash, let alone BSOD (I don't even know how it looks like now). Maybe I've been using a wrong operating system?

    Seriously though, Cg, HLSL and GLSL are restrictive enough, there is little you can do to force the crash. Sure, there are ways to mess up with the API, but I don't think using badly written shaders is one of them.

  6. #16
    Quote Originally Posted by Lifepower View Post
    but I don't think using badly written shaders is one of them.
    Think again, just check the ANGLE issues tracker (f.i. http://code.google.com/p/angleprojec.../detail?id=198). You can also have a look at the detailed driver release notes from nVidia, AMD & Intel. And if Google takes the trouble of maintaining hardware and driver compatibility lists for Chrome, believe me, that's not for the fun of it either ;-)

  7. #17
    Quote Originally Posted by Eric View Post
    Think again, just check the ANGLE issues tracker (f.i. http://code.google.com/p/angleprojec.../detail?id=198). You can also have a look at the detailed driver release notes from nVidia, AMD & Intel. And if Google takes the trouble of maintaining hardware and driver compatibility lists for Chrome, believe me, that's not for the fun of it either ;-)
    Then you should have stated that buggy software that tries to use shaders among other things, can crash PC, not shaders themselves. The link you have provided redirects to ANGLE issue tracking support. The only thing you prove by this is that ANGLE has issues but you did not address any of my shader questions.

    In any case, ANGLE is just an application of Adapter (or "wrapper" in some literature) software pattern. In no way it will help to resolve API issues as you are just redirecting OpenGL ES API, on top of which WebGL is based on, into Direct3D API. I think this will create more issues than it will solve.
    Last edited by LP; 06-03-2012 at 04:43 PM.

Page 2 of 2 FirstFirst 12

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •