Which API is better?

Discussion in 'Architecture and Products' started by DemoCoder, Oct 21, 2003.

?

Which API is Better?

  1. OpenGL2.0 is more elegant, easier to program

    329 vote(s)
    100.0%

  2. DirectX9 is more elegant, easier to program

    0 vote(s)
    0.0%

  3. Both about the same

    0 vote(s)
    0.0%

  4. I use DirectX mainly because of market size and MS is behind it

    0 vote(s)
    0.0%
Page 20 of 22
  1. Simon F

    Simon F Tea maker
    Moderator Veteran

    Joined:
    Feb 8, 2002
    Messages:
    4,563
    Likes Received:
    171
    Location:
    In the Island of Sodor, where the steam trains lie
    No. It makes developing an optimal translation more difficult but a "naive" translation very easy.

    We've been through this several times already. GLSlang provides the opportunity for greater levels of optimisation but assumes the IHV will do a good job and that may take some time. The HLSL will get to a reasonable result faster (assuming HW that is "close" to what is actually described in DX8/9!) but, in the long run, probably offers far less opportunity to get to optimal code.


    We're just going around in circles.
     
    #381 Simon F, Nov 20, 2003
  2. JohnH

    JohnH
    Regular

    Joined:
    Mar 18, 2002
    Messages:
    595
    Likes Received:
    18
    Location:
    UK
    I suggest you actually go away and write a compiler that works with the IM format, when you do this you'll see none of this is a big deal.

    I think you'll find over the next five years it won't go beyond four or five e.g. pre 2.0 (a simplification that I think you'll find a lot of ISV's agree with), 2.0, 3.0 and 4.0. Thats four profiles, with an awful lot of longevity.

    I have repeatedly explained what profiles provide, I really can't be bothered to type it all in again.
    Its exactly the point. Ignoring the point that you seem to think its impossible to optimise something once its been converted to IM format(incedentally, any case where you're multiplying by a staic constant is easy to spot), you also seem to think its a good idea to introduce more and more complicated operations into the shader. I suggest you look at the history of CPU development. Spending your area accelerating basic functions will give greater overall returns than picking out high level functions and adding dedicated HW.

    I think you find it doesn't work wrt "real time" gaming applications, generally, when talking about rasterisation functions, if its SW it doesn't get used. Otherwise you just end up titles that run at non existent frame rates on some unknown proportion of HW, maybe you can explain how that is an acceptable solution ?


    John.
     
    #382 JohnH, Nov 20, 2003
  3. Joe DeFuria

    Joe DeFuria
    Legend

    Joined:
    Feb 6, 2002
    Messages:
    5,994
    Likes Received:
    71
    I hereby nominate Simon for Poster of the Year!
     
    #383 Joe DeFuria, Nov 20, 2003
  4. KimB

    KimB
    Legend

    Joined:
    May 28, 2002
    Messages:
    12,928
    Likes Received:
    230
    Location:
    Seattle, WA
    No, it requires that IHV's will do a good job. More specifically, games that make use of GLSlang will require that IHV's do a good job with compilers. For one, I think we can be assured that John Carmack's next big project will make heavy use of GLSlang.

    And, what's more, it makes it easier for IHV's to do a good job at optimizing.
     
    #384 KimB, Nov 20, 2003
  5. Joe DeFuria

    Joe DeFuria
    Legend

    Joined:
    Feb 6, 2002
    Messages:
    5,994
    Likes Received:
    71
    Right. Requires more work / effort from the IHV.

    Yes, so we can be assured that in what, 4 years time (when Carmack's next big project hits the street), that at least those IHVs with the resources "required" to have "good" GLSL compilers, will have enough compiler support to play Carmack's engines.

    Which no one ever disputed.
     
    #385 Joe DeFuria, Nov 20, 2003
  6. Humus

    Humus Crazy coder
    Veteran

    Joined:
    Feb 6, 2002
    Messages:
    3,217
    Likes Received:
    77
    Location:
    Stockholm, Sweden
    Yeah, like the trend ps2.0a set, right? You suggested earlier that adding specific profiles for certain hardware like this was the solution to all the problems profiles otherwise have. So which is it? Only a few profiles, but with performance problems, or many profiles with large maintainance problems?

    Yes, so when it detects that MUL and removes it, then it should have another instruction slot free for use. But no, the profile would just fail to compile if the instruction count would exceed 64, regardless if the hardware can actually run it or not. Same with the added constant it add.

    It's not about adding more complicated operations. It's about letting IHVs construct their hardware the way they want, not having MS enforce a particular model. Further, MAD2X is almost for free in terms of transistors if you can do MAD.

    You need to test run it on all hardware anyway, so these problems will be spotted. Name one game or application where the OpenGL model have led to problems. I don't know any.
     
    #386 Humus, Nov 20, 2003
  7. Humus

    Humus Crazy coder
    Veteran

    Joined:
    Feb 6, 2002
    Messages:
    3,217
    Likes Received:
    77
    Location:
    Stockholm, Sweden
    No. You'll be required to do a good job, like you're required in DX. The only difference it's easier to do in GL, so it will require less work.
     
    #387 Humus, Nov 20, 2003
  8. Joe DeFuria

    Joe DeFuria
    Legend

    Joined:
    Feb 6, 2002
    Messages:
    5,994
    Likes Received:
    71
    Round and round we go...

    You'll be required to do a good job in GL, just to get a "naive implementation", unlike DX, where it's not as difficult.

    ....where she stops, nobody knows....
     
    #388 Joe DeFuria, Nov 20, 2003
  9. JohnH

    JohnH
    Regular

    Joined:
    Mar 18, 2002
    Messages:
    595
    Likes Received:
    18
    Location:
    UK
    My doctor has told me to leave this thread alone, but one last one...

    Thats because titles deliberately avoid using rasterisation functions that aren't going to be HW accelerated. With GLSlang you have no idea what is and isn't going to manage to be accelerated as the matrix is massively more complicated. Testing on every single combination of HW is becoming impractical, and its impossible to test on HW that doesn't exist yet, and, no, new HW doesn't automatically mean more native GLSlang support.

    Anyway, enough.
    John.
     
    #389 JohnH, Nov 20, 2003
  10. DemoCoder

    DemoCoder
    Veteran

    Joined:
    Feb 9, 2002
    Messages:
    4,733
    Likes Received:
    81
    Location:
    California

    Wrong Joe. A naive implementation in OpenGL looks like this:

    a) take GLSL grammar
    b) generate parser to create AST
    c) generate fragment program from AST directly. No scheduling, packing, or optimizations of any kind used.

    Steps a) and b) are done for you. You can download the grammar specification today and use a parser generator. Step c) is straightforward. Go buy a copy of a compiler book, turn to the chapter on instruction selection via tree rewriting. If you don't want to do any work, there are "Code Generator Generators" just like there are Parser Generators. These work on a bottom-up rewrite system from a grammar spec.

    The only difference between the "naive" OpenGL implementation and the "naive" DX implementation, is that the DX driver receives pre-parsed instruction tokens which it must do instruction selection for, and the OGL version receives source code, but the parser is already freely available. If anything, the OGL code probably is easier, since there are publically available BURG systems to automate code generation from ASTs, but there is no publically available tool that I am aware of for mapping DX instruction streams.
     
    #390 DemoCoder, Nov 20, 2003
  11. DemoCoder

    DemoCoder
    Veteran

    Joined:
    Feb 9, 2002
    Messages:
    4,733
    Likes Received:
    81
    Location:
    California
    No, you have agreed that MS's compiler shouldn't be doing any optimizations since these just complicate the IHV's driver which much redo them anyway.

    Therefore, profiles should not influence optimizations from MS's compiler. The compiler should try to preserve as much of the original AST as possible in the IM, that means, using branches for branches, not expanding macros, not doing CSE, or reordering blocks. Too bad the IM can't represent many functions the HW would like to accelerate.


    So what's left? Profiles as simply validation tool to ensure your HLSL code "won't break" HW by using too many resources.

    Do you really believe you can get away with just using the HLSL compiler to check your shader code statically, without running these shaders on REAL HARDWARE?


    So why not simply argue for the use of validation tools that work with the OGL GLSLANG compiler instead?

    Here's the developer process for DX:

    1) write shader in HLSL
    2) try to compile for PS3, PS2, PS1
    3) if compiler says you exhausted resources for a particular profile, you add in a new specialized case for that PS version, go back to step 1
    4) Now test your shader on hardware 1,2,3 to make sure it works without bugs, and make sure it performs adequately
    5) if it's fubar on a particular HW, go back to step one and workaround

    Here's the developer process for GLSLANG:
    1) write shader in GLSLANG
    2) use a validation tool to test shader against IHV compiler driver 1,2,3 for resource exhaustage, bugs, and performance
    3) for any HW that fails, go back to step 1

    You're trying to argue that MS's compiler will help you avoid actual testing on real HW, at best, it's a "first level check", the profiles themselves won't guarantee anything, as you well know, saying a driver is "DXn compliant" won't remove the need to test,test,test and workaround,workaround,workaround. It sure didn't help Valve. Complain about NV's busted HW all you want, it's got market share, and Valve had to do extra work around it since PS2.0 performed unacceptably on it.

    Within 1 to 2 years, I expect most HW to essentially have unlimited shader length and enough registers that it is unlikely resources will ever be exhausted. Even today, it is unlikely you'll exhaust 16 temporaries in most shaders. The focus is going to be on making stuff run fast, not "who's got higher limits", and in that case, DX9's profiles will be in trouble compared to HLSL.

    The shader profile concept for syntax and resource checking has a limited lifespan. Profiles have no concept of performance. Your argument would have merit if MS profiles stated required fillrate or instruction dispatch throughput requirements.
     
    #391 DemoCoder, Nov 20, 2003
  12. Humus

    Humus Crazy coder
    Veteran

    Joined:
    Feb 6, 2002
    Messages:
    3,217
    Likes Received:
    77
    Location:
    Stockholm, Sweden
    Yes, like titles in DX deliberately avoid functions that aren't supported in hardware. Little difference from the application programmer's POV, but a large difference from the driver implementor's point of view. It lets them expose hardware that doesn't fully comply with the spec, and let it resort to software rendering for the cases that can't be supported in hardware. Look at my latest demo for instance. In OpenGL it would run just fine on GFFX too, cause the hardware is capable of doing everything in that demo, but nVidia can't support the DX spec for floating point render targets.

    Testing on all GPUs is something you should always do anyway, regardless of API. While theorethically problems can arise with future hardware I don't know a single occasion this has happened to any GL game or application.

    There are never any guarantees regarding performance. Heck, using Truform in DX is run in software too on R300. As are vertex shaders on GF2 and Radeon cards.
     
    #392 Humus, Nov 20, 2003
  13. Frank

    Frank Certified not a majority
    Veteran

    Joined:
    Sep 21, 2003
    Messages:
    3,187
    Likes Received:
    59
    Location:
    Sittard, the Netherlands
    "So, we want to bring this game to market and make huge bucks. The less money spent on research and development, the larger the revenue. The moment it doesn't crash all the time anymore, freeze it and wrap it up. If it has a small time to live, that is good. Just make sure the next one is rushed out when the first one expires. More money for us!"

    "But, there is a slight thingy. Ehrm. You know. People have to actually buy it. You know. How do we get them to do that?"

    "Fast development! Shorter time to market! We want a common platform, that does not change. Ever. Let Microsoft make DX such, that it cannot be optimized at all. That will force hardware manufacturers to create identical chips. That cuts down the development of game-engines to zero. And all the art can be reused. We might even have to halt a game for a bit before throwing it out! :D "

    "But... How about diversification? If they're all the same, why would consumers buy them?"

    "Marketing! And we all thank Microsoft for the great job they do! We even believe it ourselves!"

    "Ah. Electronic Arts. Sports games. Just fill in the current players. It will sell anyway. Is that what you have in mind?"

    "Exactly! They showed us all how to do it!"

    "So, we should freeze any and all new developments and innovation?"

    "Yes, exactly! What money is there in that anyway? You have to pay to get R&D done, and hope for some result that might get your money back. Away with it!"

    "But then we get to a standstill! All hardware will be the same! None will be bought anymore!"

    " :) Look at Intel: Increase The Clock Rate And Market It. See? It's simple. That's how it is done. That's how you make money."

    "Ehrm... Did you listen to yourself? I mean, it doesn't make sense!"

    "Don't worry. I'm a manager. I know. That's why they pay me the Big Bucks. Leave it all to me."



    Anyway, why am I writing this? People are still discussing the "triviality" of just replacing specific sequences of a few instructions in a random stream... Think about it, Please!

    EDIT: I have my own company and one third of the shares in two others. I spend a lot of my time listening to managers "doing business".
     
    #393 Frank, Nov 21, 2003
  14. darkblu

    darkblu
    Veteran

    Joined:
    Feb 7, 2002
    Messages:
    2,642
    Likes Received:
    22
    you made my day, diguru! :D
    a good joke is one with a lot of truth in it, they say.

    on a sidenote, you know why i love japanese game titles and generally prefer those to their american/european counterparts? -- because japanese titles are made with a lot of effort - and that's plain visible in the final product, artwork- and gameplay -wise. all those minor details that make you stop and wonder 'my, did they actually bother to implement this!?'. go figure, but apparently there's a slight difference in the management philosophies between the two cultures..
     
    #394 darkblu, Nov 21, 2003
  15. KimB

    KimB
    Legend

    Joined:
    May 28, 2002
    Messages:
    12,928
    Likes Received:
    230
    Location:
    Seattle, WA
    Any good US game has been similarly thought-out. For example, I am of the opinion that the Bioware/Black Isle RPG's (Fallout, Baldur's Gate, Planescape: Torment, KoTOR etc.) were, largely, quite a bit more work and are more complete games than any Japanese RPG's.

    From my experience with games, the Japanese style is more about telling a story. The American style is more about freedom, expressing ones' self in a game environment. And any good game, from either country, will have had tons of work poured into it.

    But yes, US companies (*cough* EA *cough*) do put out tons of crap games.
     
    #395 KimB, Nov 22, 2003
  16. Joe DeFuria

    Joe DeFuria
    Legend

    Joined:
    Feb 6, 2002
    Messages:
    5,994
    Likes Received:
    71
    Isn't this a blast from the past. ;)

    I stumbled back upon this thread when searching for something else...

    So now I'm wondering...a year later...where IS nVidia's official GLSL compiler in any decent form....for any of their chips?

    I would have thought a "naive" implemention would be a snap according to some people....
     
    #396 Joe DeFuria, Apr 24, 2004
  17. DemoCoder

    DemoCoder
    Veteran

    Joined:
    Feb 9, 2002
    Messages:
    4,733
    Likes Received:
    81
    Location:
    California
    First, what does this have to do with NVidia? This thread had nothing to do with NVidia yet you drag them into it, and was a discussion of APIs (OGL compiler approach vs Microsoft compiler approach) What's your point? A year later? This thread is from November. OpenGL1.5 wasn't even released until Aug 2003.

    1) NVidia: ftp://download.nvidia.com/developer/SDK/56.68_win2kxp_international_glsl.exe
    ATI: Catalyst 3.1 and beyond
    3dLabs: current P10 driver

    Naive implementations right? Egg on your face Joe.

    (is "decent form" supposed to be your weasel out phrase to deny the existence? Yes, they have some bugs (just like MS's compiler), but isn't that what you'd expect from a Naive implementation of something that isn't even ratified into the Core opengl yet?)

    Second, everything I have said has come to pass, going back to 2-3 years ago on this bbs. I wish the archives included the old messages before 2002, I said:

    1) compilers will become vitally important for future GPUs as they increase in complexity (I said this when DX8 came out)

    2) That problems inherent with Microsoft's compiler could sabotage future GPU performance (example I gave was hardware support for Normalize(), lo-and-behold, Nvidia added it, for nrm_pp). FXC has finally been fixed to generate NRM. Too bad for any games that don't have the NRM macro in the DX9 shaders. Let's hope the drivers can detect it.

    Now the issue is what happens to co-issue/dual-issue scheduling, and choosing cmp vs predicate vs dynamic branch. MS will need to create a PS_3_0_NV40 profile, since generic compilation to PS3.0 will be unaware of the varying costs (say of a branch on NV40 vs 3dLabs Realizm)

    3) Most of the work is in the backend. Once ATI and NVidia complete the test GLSL extensions for NV30/R300, it will be much easier to translate these to the NV40/R420.

    Next time you did up an old thread to harass me, maybe you should choose one where I was uncontrovertably wrong.
     
    #397 DemoCoder, Apr 24, 2004
  18. Joe DeFuria

    Joe DeFuria
    Legend

    Joined:
    Feb 6, 2002
    Messages:
    5,994
    Likes Received:
    71
    Um, nVidia just launched PS 3.0 hardware, perhaps? I'm waiting for nVidia to deliver their GLSL drivers before they deliver a HLSL driver that supports PS 3.0?

    Does nVidia even have a GLSL driver that is officially exposed in their public drivers? They've had HLSL support for quite a while now.

    No, "naive" implementation was something heavily disccused throughout this topic.

    No argument there. (Would anyone argue such an obvious assertion?)

    And here I thought you also said something like:

    Yeah...the 6800 really seems to suffer with PS 2.0 shaders right off the bat...

    Next time, understand the entire argument being made. I think we'll be seeing PS 3.0 HLSL support from day one....and YES...it will need further optimization...but it will be there.
     
    #398 Joe DeFuria, Apr 24, 2004
  19. DemoCoder

    DemoCoder
    Veteran

    Joined:
    Feb 9, 2002
    Messages:
    4,733
    Likes Received:
    81
    Location:
    California
    First of all, I said shipping, not launched, implying near term drivers when it goes into the hands of consumers. (any NV40s being sold on shelves yet with final drivers?) Secondly, where did I ever say NVidia would deliver a GLSL driver before a PS3.0 driver, or for ANY vendor for that matter? Do you find the need to put words into people's mouths to buttress your argument.

    I simply said that most of the hard work of optimizing is already done by the *driver compiler* which works on PS2.x token streams. I said writing the PARSER for the high level language is trivial (it is), and but that problems in the intermediate representation (PS2.x) and how Microsoft's static compiler chooses instructions, could cause problems that a GLSL compiler inside the driver wouldn't.

    Get a friggin clue.

    Technicall, MS provides HLSL support in D3DX, not NVidia. But of course, NVidia has a HLSL compiler of their own written from scratch, thanks to Cg. But isn't writing compilers supposed to be so hard that IHVs can't do it in a timely manner? How'd Nvidia write their own HLSL compiler 1+ year ago?

    (there are few differences between the HLSL language and the GLSL language)

    Obvious in hindsight for you, not obvious in foresight when I said it. Several people criticized my statement saying that optimizing the assembly for GPUs was "trivial" to schedule, and therefore, not a problem. Of course, DX8 was the only shding language at the time, and it did look trivial. No branches, no register limits, basically register combiners. What looked trivial in 2001 doesn't look so trivial now.

    The point of that quote (taken out of context by you again because of your lack of understanding) was that *drivers and driver compilers* can be upgraded by IHVs to give performance boosts, where as static compilers like Microsofts required rebuilding your game and shipping a PATCH.

    The analogy was to say that if a problem was found in MS's compiler and fixed, developers would have to ship game patches before end users could realize the improved performance, whereas with *compilers built into drivers* IHVs can ship drivers with give across the board performance increases. Compilers are already inside today's drivers, so the discussion is moot. The only thing not inside the driver is the high level grammar parser, some generic optimizations, and instruction selection.


    You're the one who doesn't understand compiler issues Joe, not me.
     
    #399 DemoCoder, Apr 24, 2004
  20. Joe DeFuria

    Joe DeFuria
    Legend

    Joined:
    Feb 6, 2002
    Messages:
    5,994
    Likes Received:
    71
    Awww...we're getting picky now, eh?

    No, there are no NV40s being sold, just year old NV30s...

    So, if you don't disagree with me...why argur?

    Do you need to make side arguments that are only tangental to mine to avoid conceding a point?


    I'm still waiting to see how all of this (GLSL approach) has in fact practically benefitted the consumer. Get your own friggin clue.

    GOOD and robust ones?

    BEcause it was a piece of crap 1+ years ago? Or did was (and still is?) HLSL compiling BETTER (performance and bugs) than Gc not exactly what happened? I could've sworn that the Cg compiler was a big sore spot of the whole effort...

    So in any situation...you still need to download "a patch." And of course...with "compilers built into drivers" that have "across the board increases / fixes", you seem to have negated the "it can BREAK apps that happened to 'rely' on the older functionality" effect.

    Yay...id tells me to download the latest driver, which does wonders for Doom3...but breaks whatever other game someone decides to actually code in GL.

    I'm also the one who has actually seen and touched a few games that have been released / compiled with HLSL shaders. Still waiting for those GLSL titles...for all it's superiority....
     
    #400 Joe DeFuria, Apr 24, 2004
(You must log in or sign up to post here.)
Page 20 of 22
Loading...
Similar Threads - better
  1. JPT

    Interesting bit about how Apple helped TSMC to become better

    JPT, Mar 11, 2022, in forum: Console Technology
    Replies:
    4
    Views:
    932
    Entropy
    Mar 12, 2022
  2. wco81

    Qualcomm acquires startup of former Apple employees to better compete vs. Apple

    wco81, Jan 13, 2021, in forum: Mobile Industry
    Replies:
    1
    Views:
    1,831
    glow
    Jan 14, 2021
  3. Sycologist

    New Edge browser has much better memory management than Chrome

    Sycologist, Sep 7, 2020, in forum: PC Hardware, Software and Displays
    Replies:
    44
    Views:
    6,258
    pharma
    Dec 30, 2021
  4. DieH@rd

    We need a better way of presenting Digital Events [2020]

    DieH@rd, Jun 16, 2020, in forum: Console Industry
    Replies:
    37
    Views:
    2,477
    ultragpu
    Jun 29, 2020
  5. Cyan

    Xbox gamers have better reflex than Playstation gamers.

    Cyan, Jan 15, 2019, in forum: Console Industry
    Replies:
    15
    Views:
    1,624
    DrJay24
    Jan 17, 2019
  6. Poppy1937

    Is the battery life of the iphone better?

    Poppy1937, Oct 25, 2018, in forum: Mobile Devices and SoCs
    Replies:
    17
    Views:
    8,971
    swaaye
    Jul 10, 2020

Share This Page

Toggle Width
Style
Beyond3D

  • About Us

    Beyond3D has been around for over a decade and prides itself on being the best place on the web for in-depth, technically-driven discussion and analysis of 3D graphics hardware. If you love pixels and transistors, you've come to the right place!

    Beyond3D is proudly published by GPU Tools Ltd.

  • Quick Navigation

Loading...