Page 7 of 7 FirstFirst ... 567
Results 61 to 69 of 69

Thread: Next-Gen OpenGL To Be Announced Next Month

  1. #61
    Join Date
    Jul 2010
    Posts
    447

    Default

    Quote Originally Posted by Ancurio View Post
    I didn't say any of them abstracted 3D rendering. If you're going to do 3D, you're not going to want to go higher than OGL/D3D in the first place; what I meant was that the people who complain the most that their "convenient" glBegin/glEnd stuff is deprecated/gone in modern GL are the ones only aiming to render simple rectangles (2D games) anyways. For those people, there is no reason to use OGL directly.
    I somehow had the impression the topic would be about high and low level 3D APIs, and not about people having problems to draw a friggin rectangle. My apologies.

  2. #62
    Join Date
    Oct 2013
    Posts
    307

    Default

    Quote Originally Posted by przemoli View Post
    If You mean, absolute performance? Then yes Nvidia did great job. My speculation is that they aimed at those fast patch for some time now, and they have optimised driver and maybe even some hw to accelerate it more.

    But if You mean, that AMD/Intel fail, than its big fat NO. F**** NO.

    Both AMD and Intel see 1000% or more improvements by selecting right way of doing things.

    End performance may be less than for Nvidia but its still much better than old ways for AMD/Intel.

    No excuse for not to adopt AZDO.

    (And while one of those extensions is from OpenGL 4.4. Core, it can be implemented as extension without claiming even 4.0 as may happen for Mesa. OpenGL 4.x level of hw is required, but not full OpenGL 4.4)
    nope, they didn't optimize things. they just made them work as they should.

    in my simple mind i can imagine this. correctly implemented extension multidraw_indirect will take path where it completely avoids setting state as per specs and make it damn fast, but it will take a lot of work and testing. lame developer on the other hand can implement it in 2min by simply putting usual render queue loop to parse arrays.

    in later,... multidraw_indirect end result will be correct, but with 100% same abysmal performance as GL 3.3. sadly, later implementation counts as implementation just as the one that did job as needed.

    if you check the tests people did on this extension. amd and intel perform with same speed as without.

    same lame 2min implementations can be done for each and every zero-overhead needed extension.

  3. #63
    Join Date
    Sep 2013
    Posts
    176

    Default

    Little of off topic, but might be other AMD developers read this.
    Where is Graham Sellers disappear from twitter?

    I'm waited to see his comments about GL future so much, but no news for about a month. Hope he's alright...

  4. #64
    Join Date
    Sep 2010
    Posts
    654

    Default

    Quote Originally Posted by justmy2cents View Post
    nope, they didn't optimize things. they just made them work as they should.

    in my simple mind i can imagine this. correctly implemented extension multidraw_indirect will take path where it completely avoids setting state as per specs and make it damn fast, but it will take a lot of work and testing. lame developer on the other hand can implement it in 2min by simply putting usual render queue loop to parse arrays.

    in later,... multidraw_indirect end result will be correct, but with 100% same abysmal performance as GL 3.3. sadly, later implementation counts as implementation just as the one that did job as needed.

    if you check the tests people did on this extension. amd and intel perform with same speed as without.

    same lame 2min implementations can be done for each and every zero-overhead needed extension.
    That was actually first AMD implementation.

    Some 2 weeks after some GL dev proposed it.

    So this implementation is still good for:
    a) When hw is not able to execute such single call and it must be split by the driver
    b) Decreasing need for fallbacks (since new way is faster on new designs and at least as fast on old ones, ...)

    End goal is for hw execution.

    That is Nvidia vision. And You can see that in the apitest results for them.

    AMD and Intel both lag behind, but they DO make this a better technique then "older" OpenGL paths.

    So no excuse to not to use (and little excuse to rant about it :P)

  5. #65
    Join Date
    Oct 2013
    Posts
    307

    Default

    Quote Originally Posted by przemoli View Post
    That was actually first AMD implementation.

    Some 2 weeks after some GL dev proposed it.

    So this implementation is still good for:
    a) When hw is not able to execute such single call and it must be split by the driver
    b) Decreasing need for fallbacks (since new way is faster on new designs and at least as fast on old ones, ...)

    End goal is for hw execution.

    That is Nvidia vision. And You can see that in the apitest results for them.

    AMD and Intel both lag behind, but they DO make this a better technique then "older" OpenGL paths.

    So no excuse to not to use (and little excuse to rant about it :P)
    not ranting, at least i didn't mean to. i only use NVidia for gaming and this doesn't touch me. still, it is way past 2 weeks with no results from any other company than NVidia and if people go with your proposed mentality into the game performance. why not simply make software renderer and it will work everywhere. off course, it will work <1fps, but who cares. important thing is every card on the world is supported and developers can use ?fast path?

    and even if you tried to use it like you say, some features like fencing, persistent buffers, texture arrays would impose uncontrollable problems. part of making the game is also controlling how much and how fast you feed to GPU and VRAM. so, any game that would try working faster and more than 3.3 was capable would kill it self by default. this brings the need to limit resources where one would need to keep 2 versions of the game. simpler and complex

  6. #66
    Join Date
    Sep 2010
    Posts
    654

    Default

    Quote Originally Posted by justmy2cents View Post
    not ranting, at least i didn't mean to. i only use NVidia for gaming and this doesn't touch me. still, it is way past 2 weeks with no results from any other company than NVidia and if people go with your proposed mentality into the game performance. why not simply make software renderer and it will work everywhere. off course, it will work <1fps, but who cares. important thing is every card on the world is supported and developers can use ?fast path?

    and even if you tried to use it like you say, some features like fencing, persistent buffers, texture arrays would impose uncontrollable problems. part of making the game is also controlling how much and how fast you feed to GPU and VRAM. so, any game that would try working faster and more than 3.3 was capable would kill it self by default. this brings the need to limit resources where one would need to keep 2 versions of the game. simpler and complex
    Driver-only implementation (and I do not know if AMD still use it or for what hw!), do not pose problems with other things for OpenGL app.

    With or without MDI driver need to take care of those too.

  7. #67
    Join Date
    Oct 2013
    Posts
    307

    Default

    Quote Originally Posted by przemoli View Post
    Driver-only implementation (and I do not know if AMD still use it or for what hw!), do not pose problems with other things for OpenGL app.

    With or without MDI driver need to take care of those too.
    it is kinda obvious you didn't understand my point.

    having "best opengl path" is 10% of the problem. in old days gpu was simply not capable rendering as much as you could feed it. at that time faster gpu ment everything. gpus evolved and right now you CAN'T feed it as much as it could render (why do you think cpu is gaming bottleneck). that is why avoiding state setting between ops and syncing means so much. waiting for gpu to be free, setting it up, do your single action, reseting... 90% of the time you used to wait and do useless things.

    if you do implementation of multidraw_indirect that just parses arrays and then sync, set, draw one, reset, rinse and repeat... welcome, you just created nightmare, where there is >1000% randomness. you avoid ?has_extension? with introducing ?does_it_actually_work?. and later is worse than former. you really did create single path how to code, you just don't have a clue if it works

    well, it is even worse since some hw can and some can't. it just breaks whole meaning. it's like allowing people with bikes driving on the freeway, utter chaos. difference in speed is too big to be controlled.

    and don't misunderstand me, i'll praise the world, amd and intel if it works out for them. they could do few approaches to lessen the pain, still it won't beat hw. also, i love amd on simple desktop and i love intel on servers. i would even be prepared to pay double price for amd (by buying higher price range) if it performed as well as some 750 or 760 and that meant i can avoid blob

  8. #68
    Join Date
    Oct 2013
    Location
    Canada
    Posts
    315

    Default

    Quote Originally Posted by justmy2cents View Post
    it is kinda obvious you didn't understand my point.

    having "best opengl path" is 10% of the problem. in old days gpu was simply not capable rendering as much as you could feed it. at that time faster gpu ment everything. gpus evolved and right now you CAN'T feed it as much as it could render (why do you think cpu is gaming bottleneck). that is why avoiding state setting between ops and syncing means so much. waiting for gpu to be free, setting it up, do your single action, reseting... 90% of the time you used to wait and do useless things.

    if you do implementation of multidraw_indirect that just parses arrays and then sync, set, draw one, reset, rinse and repeat... welcome, you just created nightmare, where there is >1000% randomness. you avoid ?has_extension? with introducing ?does_it_actually_work?. and later is worse than former. you really did create single path how to code, you just don't have a clue if it works

    well, it is even worse since some hw can and some can't. it just breaks whole meaning. it's like allowing people with bikes driving on the freeway, utter chaos. difference in speed is too big to be controlled.

    and don't misunderstand me, i'll praise the world, amd and intel if it works out for them. they could do few approaches to lessen the pain, still it won't beat hw. also, i love amd on simple desktop and i love intel on servers. i would even be prepared to pay double price for amd (by buying higher price range) if it performed as well as some 750 or 760 and that meant i can avoid blob
    I've linked to another article/benchmark/review before, but anyways, Mantle seems to better benefit the computers that have a CPU bottleneck, not so much the ones with the wicked fast processors because then they start running into a GPU bottleneck.

  9. #69
    Join Date
    Jun 2012
    Posts
    336

    Default

    Quote Originally Posted by profoundWHALE View Post
    I've linked to another article/benchmark/review before, but anyways, Mantle seems to better benefit the computers that have a CPU bottleneck, not so much the ones with the wicked fast processors because then they start running into a GPU bottleneck.
    Pretty much. Mantel isn't improving the rendering backend much, its lowering the demand of the drivers main thread. That's where the performance benefit is coming from.

Posting Permissions

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