Page 3 of 8 FirstFirst 12345 ... LastLast
Results 21 to 30 of 75

Thread: Next-Gen OpenGL To Be Announced Next Month

  1. #21
    Join Date
    Oct 2008
    Posts
    120

    Default "lover overhead OpenGL"

    Quote Originally Posted by phoronix View Post
    FTA: 'Hearing about "lover overhead OpenGL" is hardly a surprise'
    Did it just get... sexy... in here?

  2. #22
    Join Date
    Oct 2013
    Location
    Canada
    Posts
    413

    Default

    I noticed that and it immediately made my day.

  3. #23
    Join Date
    Jan 2009
    Location
    Outthere, NSW, Australia
    Posts
    402

    Default

    Quote Originally Posted by Kivada View Post
    You mean DX10.1 right? IIRC it's because AMD was the first one to support it by a long shot, there where a few games that implemented it, even some that removed the capability because Nvidia paid them off as DX10.1 made the games run noticeably faster then DX10.
    huh, that might actually explain part of why Age of Conan went a little bit funky around 2010, after they 'revamped' their GFX engine. Which sucked harder than the original.

  4. #24
    Join Date
    Oct 2013
    Posts
    417

    Default

    Quote Originally Posted by zxy_thf View Post
    In short, the old APIs were not designed to be efficient
    select VS epoll is a good example.
    i might be wrong here, but zero-overhead on GL was presented with up to 4.4 extensions. only problem is that only nvidia did their work and actually made them perform as they should. feature wise, nothing should stop any 4.4 card to employ it, even if 5 would describe some nicer api. in my opinion, card makers won't do that since they are in business of selling new cards, not refurbishing old ones

    unless you meant some other view on efficient

  5. #25
    Join Date
    Aug 2011
    Posts
    542

    Default

    Quote Originally Posted by jrch2k8 View Post
    Problem is not that the drivers are sending millions of additional opcodes and trashing the command dispatchers or not using certain uber optimised paths or nothing like that.

    The actual problem is hardware bandwidth/latency even if PCIe is really fast is not that fast so every upload to GPU ram is gonna hurt a lot, so the efficiency focus is a standard way to remove the upload process as much as possible and keep data inside the GPU ram as much as is possible to save PCIe trips to the CPU and backwards, ofc this will increase GPU ram usage(you can't have both ways) and start up times(you have to upload more data to avoid multiple/serial uploads), for example:

    Current OpenGL/DX game: upload TextureA, wait for upload(hurts and hurts and hurts), process, Upload TextureB, wait for upload(hurts and hurts and hurts), process,render.

    Next Gen OpenGL/DX game: upload TextureA,B,C,N... to buffersA,B,C,N ...(<-- only once per scene), reference buffer A, process, reference buffer B, process, render

    Of course many more factors need to work that way, the example is just a very bastardised way to show part of the problem
    Can't you do that kind of stuff with decoding texture image data directly to mapped PBOs and then uploading from that?

  6. #26
    Join Date
    Jan 2009
    Posts
    1,439

    Default

    Quote Originally Posted by justmy2cents View Post
    i might be wrong here, but zero-overhead on GL was presented with up to 4.4 extensions. only problem is that only nvidia did their work and actually made them perform as they should. feature wise, nothing should stop any 4.4 card to employ it, even if 5 would describe some nicer api. in my opinion, card makers won't do that since they are in business of selling new cards, not refurbishing old ones

    unless you meant some other view on efficient
    Are you sure about this? AZDO was a joint effort from devs at AMD, Intel and nvidia. It seems odd if their joint effort only ran correctly on one of the platforms.

  7. #27
    Join Date
    Sep 2010
    Posts
    702

    Default

    Quote Originally Posted by justmy2cents View Post
    i might be wrong here, but zero-overhead on GL was presented with up to 4.4 extensions. only problem is that only nvidia did their work and actually made them perform as they should. feature wise, nothing should stop any 4.4 card to employ it, even if 5 would describe some nicer api. in my opinion, card makers won't do that since they are in business of selling new cards, not refurbishing old ones

    unless you meant some other view on efficient
    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)

  8. #28
    Join Date
    Dec 2012
    Posts
    200

    Default

    OpenGL 5 needs a complete clean-sheet API , with drivers maintaining GL <= 4.4 APIs for compatibility. Contexts and libraries for OpenGL 5 and earlier versions should be completely separated. For example, in order to create a OpenGL 5 or later context you should specify the version.
    Last edited by newwen; 07-16-2014 at 04:10 AM.

  9. #29
    Join Date
    May 2011
    Posts
    55

    Default

    OpenGL5 will be async? And have functions with callback?

  10. #30
    Join Date
    Feb 2009
    Posts
    165

    Default

    Quote Originally Posted by stalkerg View Post
    OpenGL5 will be async? And have functions with callback?
    OpenGL is already async. There are no callbacks that I'm aware of, however there are fences/sync objects.

Posting Permissions

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