Announcement

Collapse
No announcement yet.

Former Valve/VOGL Dev: OpenGL Next Could Take 3+ Years

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • johnc
    replied
    Originally posted by Azpegath View Post
    And like Khronos' Chairman said during the Siggraph presentation: "If we don't get this out within a reasonable time, OpenGL will be dead".
    He actually said that and was being serious?

    Leave a comment:


  • jrch2k8
    replied
    well if my understanding of metal and mantle is rightish, it should be a swift to implement in mesa gallium drivers(for intel will require an external lib and a bunch of infrastructure code tho) because thanks to TGSI gallium can go as low as needed and is isolated from any high level language (this is why state trackers are awesome), so if i'm right metal and mantle allow you to access opcodes directly with some infrastructure to make it easyish and manipulate with some infrastructure map high level language generated buffers,tex, stencil, etc. directly.

    ofc there is no documentation yet but from what i can get from the available information mantle sound an awful lot like an conceptual gallium state tracker and i believe as long a gallium driver is used an state tracker can transparently interact with OpenGL and the rendering process (not 100% sure)

    Leave a comment:


  • Azpegath
    replied
    Originally posted by Meteorhead View Post
    That will simply never happen. If that would be acceptable, NV and Intel would already support Mantle. Personally I would not be happy to see OpenGL-Next to be a copy of Mantle. I believe it would be a lot more reasonable if they created an ABI and an API that integrated better with OpenCL. I have abso****inglutely no idea what's the need for OpenGL Compute Shaders, when they have a compute API available that is far superior to something hacked onto a graphics API. The only reason people use GLCS is because it outperforms CL-GL interop. If they'd design an ABI that is more flexible than current interop, and one which outperforms it, (if OpenGL could inherit the SPIR intermediate, if people could link OpenGL shaders with OpenCL kernels) that would make a lot more sense from a Khronos perspective. If single-source shaders could be written with a tool similar to SYCL, graphics and compute merged to C++ in a single-source manner... Khronos has a lot of good technologies. I think it would be wiser if they brought together what they have rather then creating something yet again radically new. Just get rid of the anachronistic stuff, give SVM to graphics (a portable means to implement partially resident textures) and bring it up to a C++ level.

    Khronos could get something working a lot faster if it reused technologies already at hand. That way at least NVIDIA would be forced to give proper support to OpenCL.
    OpenGL Next will look somewhat like Mantle, just like previous commenters' said. At least according to Khronos, even if they haven't said that officially. NVidia is fully onboard with that, mostly because the fact that hardware looks like Mantle. I also think that "within a year" is more of a likely guess, since they are fully committed to releasing something as fast as possible. Perhaps not getting everything right with the first release, but it's an iterative process.
    Is it anything that Khronos has learned from Longs Peaks and ever since (the iterative development of OpenGL 3.0 -> 4.5) is that it's sometimes more important of doing something than doing something perfect. And like Khronos' Chairman said during the Siggraph presentation: "If we don't get this out within a reasonable time, OpenGL will be dead".

    Leave a comment:


  • Pecisk
    replied
    Originally posted by zanny View Post
    OpenGL 4.5 was the answer to DX12 and Mantle. DSA and indirect calls are plenty enough to get extremely low driver overhead.

    The real problem is just getting there on drivers. Mesa might be at 4.5 in time for GL Next to come out, though.

    Fundamentally, the problem with OpenGL right now is not the modern API - it is the inability to write software using it.
    So much this.

    Technically OpenGL 4.5 is good enough to have high quality games delivered on Linux platform. What we have now is drivers chashing this target and improving compatibility.

    Also I really doubt it will take 3+ years to get to OpenGL 5. Spec will be delivered much sooner, because of commercial interests involved in this project - and fact they don't have to carter to legacy vendors anymore. Delivering it on hardware will be completely another matter, but I expect OpenGL 5 cards rolled out at 2016 fall.

    Leave a comment:


  • Meteorhead
    replied
    Originally posted by iniside View Post
    Or, maybe.. Take AMD proposal (they offered Mantle to Khronos).
    That will simply never happen. If that would be acceptable, NV and Intel would already support Mantle. Personally I would not be happy to see OpenGL-Next to be a copy of Mantle. I believe it would be a lot more reasonable if they created an ABI and an API that integrated better with OpenCL. I have abso****inglutely no idea what's the need for OpenGL Compute Shaders, when they have a compute API available that is far superior to something hacked onto a graphics API. The only reason people use GLCS is because it outperforms CL-GL interop. If they'd design an ABI that is more flexible than current interop, and one which outperforms it, (if OpenGL could inherit the SPIR intermediate, if people could link OpenGL shaders with OpenCL kernels) that would make a lot more sense from a Khronos perspective. If single-source shaders could be written with a tool similar to SYCL, graphics and compute merged to C++ in a single-source manner... Khronos has a lot of good technologies. I think it would be wiser if they brought together what they have rather then creating something yet again radically new. Just get rid of the anachronistic stuff, give SVM to graphics (a portable means to implement partially resident textures) and bring it up to a C++ level.

    Khronos could get something working a lot faster if it reused technologies already at hand. That way at least NVIDIA would be forced to give proper support to OpenCL.

    Leave a comment:


  • zanny
    replied
    OpenGL 4.5 was the answer to DX12 and Mantle. DSA and indirect calls are plenty enough to get extremely low driver overhead.

    The real problem is just getting there on drivers. Mesa might be at 4.5 in time for GL Next to come out, though.

    Fundamentally, the problem with OpenGL right now is not the modern API - it is the inability to write software using it.

    Leave a comment:


  • Temar
    replied
    "Rich Geldreich", I really love that name. Literally translated his name is "Rich Moneyrich".

    I hope he can live up to his name :-)

    Leave a comment:


  • Meteorhead
    replied
    What are your opinions on open-source NVIDIA drivers to support Mantle on Linux once the docs are public?

    Leave a comment:


  • iniside
    replied
    Originally posted by Dukenukemx View Post
    If that's the situation then we really need Mantle on Linux.
    Or, maybe.. Take AMD proposal (they offered Mantle to Khronos).

    Then, just make Mantle working on all hardware and rebrand it as OpenGL Next. Everyone is happy. OpenGL Next, in next year.

    Edit:
    I disagree about GPU support (hardware side). OpenGL Next will be copatibie with current generation of GPUs. Kepler, Maxwell, GCN 2.0. These are still high end architecture, which existing APIs still doesn't support to full extent.

    First iteration of OpenGL Next will probably focus, on catching up to existing hardware.
    Last edited by iniside; 09 October 2014, 12:09 PM.

    Leave a comment:


  • magika
    replied
    >Mantle on linux.
    >D3D12

    How about no?

    Leave a comment:

Working...
X