Announcement

Collapse
No announcement yet.

Vulkan 1.0.4 Specification Published

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

  • rob11311
    replied
    Originally posted by bug77 View Post
    I think we have a very different understanding of where OpenGL stands and where it's going. Even so, I don't see why high level Vulkan libraries should preclude OpenGL from working with Vulkan as well. At the very least, said libraries are extremely new while OpenGL is an already known alternative.
    There must be at least a little experimentation if we're to find a robust solution for the next 20+ years.
    One idea discussed by developers was (re-)implementing OpenGL in terms of Vulkan. A key to understand is that OpenGL has ideas of state tracking, which inevitibly in multi-threaded leads to contention for locks, which is really the reason for the lower level close-to-metal APIs, which are a better fitted for todays many-core hardware scenarios.

    There probably will arise helper libraries, which aid applications or engine with the differences in memory managment, they're more flexible than adding an abstraction layer; which probably won't stand the test of time (see the middle layer mistake anti-pattern for past experience on this dealing with hardware which evolves and experiments).

    Leave a comment:


  • Philip
    replied
    Originally posted by uid313 View Post
    I was thinking that maybe Vulkan is a clean, easy-to-use, modern API and a good thing to learn?

    And that maybe OpenGL is a complicated, cumbersome, inconsistent, weird API full of legacy warts?
    I think you're correct on all of those points except one: Vulkan is not easy-to-use. It forces you to do a lot of low-level work that the OpenGL driver previously would have done for you, and there are some fundamental details that vary across GPU vendors (e.g. what memory heaps you have access to) so you need to write and test multiple code paths if you want reasonable performance, and there are lots of subtle details you can get wrong without noticing that will lead to undefined behaviour (i.e. it might work fine for you but explode on someone else's GPU).

    Vulkan plus some hypothetical not-yet-existent middleware library that handles all the boring low-level details could make it easy-to-use while continuing to be clean and modern, though.

    Leave a comment:


  • liam
    replied
    Originally posted by chithanh View Post
    azari
    I'm sure the VR developers who made the 60% observation are already aware of DX12/Vulkan.
    Also while Vulkan is a console-like low-level API, there is probably still some abstraction involved to make the games run on different hardware.

    There is one very interesting Interview by Eurogamer with 4A Games about Metro Redux development on consoles. Note how besides the low-level interface they also talk about adapting to the target hardware.

    So while DX12/Vulkan will reduce the PS4's edge over a similar spec PC especially when it comes to draw call bound scenarios, it will not eliminate it fully.
    Abstractions don't necessarily mean slower. Rust even makes this one of their big selling points.

    Leave a comment:


  • bug77
    replied
    Originally posted by azari View Post

    A better way to do this however is to use opensource middleware libraries that will run on top of Vulkan, and hide some of it's intimidating low level aspects; there is already an opensource GLSL compiler that runs on top of Vulkan. That's a far better solution, whereas Nvidia's solution essentially keeps applications dependent on OpenGL for longer. OpenGL should really only matter for legacy apps; if people need user-friendly toolkits for Vulkan, those will arrive (and some have already) in due time. The driver maintenance hell that results from OpenGL in the Linux world needs to end. =\
    I think we have a very different understanding of where OpenGL stands and where it's going. Even so, I don't see why high level Vulkan libraries should preclude OpenGL from working with Vulkan as well. At the very least, said libraries are extremely new while OpenGL is an already known alternative.
    There must be at least a little experimentation if we're to find a robust solution for the next 20+ years.

    Leave a comment:


  • chithanh
    replied
    azari
    I'm sure the VR developers who made the 60% observation are already aware of DX12/Vulkan.
    Also while Vulkan is a console-like low-level API, there is probably still some abstraction involved to make the games run on different hardware.

    There is one very interesting Interview by Eurogamer with 4A Games about Metro Redux development on consoles. Note how besides the low-level interface they also talk about adapting to the target hardware.

    So while DX12/Vulkan will reduce the PS4's edge over a similar spec PC especially when it comes to draw call bound scenarios, it will not eliminate it fully.

    Leave a comment:


  • azari
    replied
    Originally posted by bug77 View Post
    This is probably why one of Nvidia 's first extensions is running Vulkan inside OpenGL. Similar to how you write C code, but when you absolutely must squeeze every bit of performance you write ASM functions inside the C code.
    A better way to do this however is to use opensource middleware libraries that will run on top of Vulkan, and hide some of it's intimidating low level aspects; there is already an opensource GLSL compiler that runs on top of Vulkan. That's a far better solution, whereas Nvidia's solution essentially keeps applications dependent on OpenGL for longer. OpenGL should really only matter for legacy apps; if people need user-friendly toolkits for Vulkan, those will arrive (and some have already) in due time. The driver maintenance hell that results from OpenGL in the Linux world needs to end. =\

    Originally posted by chithanh View Post
    "PC" was the term used by the source. While technically you are correct that PC is not an API, when talking about PC gaming up to now this almost exclusively means Windows and DirectX 11, with newcomers DirectX 12, Vulkan and non-Windows operating systems.
    The whole point of Vulkan/DX12 is to bring the close-to-metal performance that consoles like the PS4 have, to the PC; I think what eydee was pointing out was that making a comparison of "PS4's API vs PC" seems to imply that you're stacking the deck by comparing a low level API to DX11/OpenGL. Comparing PS4's low level API to Vulkan/DX12 is far more accurate, and in that case I doubt the PS4 will have much if any of an edge at all. The era of consoles getting more bang for buck on their GPUs is coming to an end.

    Leave a comment:


  • chithanh
    replied
    Originally posted by eydee View Post
    PC is not an API. This is like saying that cars are faster than vehicles.
    "PC" was the term used by the source. While technically you are correct that PC is not an API, when talking about PC gaming up to now this almost exclusively means Windows and DirectX 11, with newcomers DirectX 12, Vulkan and non-Windows operating systems.

    Leave a comment:


  • bug77
    replied
    Originally posted by uid313 View Post

    I was thinking that maybe Vulkan is a clean, easy-to-use, modern API and a good thing to learn?

    And that maybe OpenGL is a complicated, cumbersome, inconsistent, weird API full of legacy warts?

    But I really don't know.
    I think it's the other way around. OpenGL manages more things for you so it's easier to develop for, whereas Vulkan gives you more control, but then you actually have to exercise said control.
    This is probably why one of Nvidia 's first extensions is running Vulkan inside OpenGL. Similar to how you write C code, but when you absolutely must squeeze every bit of performance you write ASM functions inside the C code.

    Leave a comment:


  • uid313
    replied
    Originally posted by rob11311 View Post
    What'd be the point in Python? There's still a global interpreter lock, so draw calls would be single threaded, which means there's little downside to the OpenGL state tracking.
    Both Python & Ruby are slow anyway, have you any evidence to suggest the OpenGL API is the bottleneck for these languags?
    May be you could pass off things to a graphics engine and just use the scripted parts, for config and setup.
    I was thinking that maybe Vulkan is a clean, easy-to-use, modern API and a good thing to learn?

    And that maybe OpenGL is a complicated, cumbersome, inconsistent, weird API full of legacy warts?

    But I really don't know.

    Leave a comment:


  • eydee
    replied
    Originally posted by chithanh View Post
    PS4 API, about 60% gain over PC with equivalent specs.
    PC is not an API. This is like saying that cars are faster than vehicles.

    Leave a comment:

Working...
X