7 ms·

Vulkan could very well be a different story, it doesn't have OpenGL's shortcomings.

by vardump 10y ago

pjmlp 10y ago
The PS4 API is already much better than Vulkan.
- vardump 10y ago
  Except in portability.
  - cobalt 10y ago
    given how tailored games are already anyway, as well as wanting to be as low level as possible, that wont really matter
    - vardump 10y ago
      Vulkan is pretty close to "as low level as possible". If it's available, it'll certainly be a tempting target for those who have lower budget and those who need to port it faster.
- pcwalton 10y ago
  Can you describe how, specifically?
  - pjmlp 10y ago
    Here is a NDA free presentation I can point to. http://develop.scee.net/wp-content/uploads/2014/11/ParisGC2013Final.pdf http://develop.scee.net/wp-content/uploads/2014/11/ParisGC20... Starts on slide 32 for the graphics part.
    - pcwalton 10y ago
      As I suspected, all of the features that I can see described here are in Vulkan. In particular, the first couple of slides pretty much identically resemble Vulkan's "elevator pitch". The presentation is from 2014, so when they claim "better than DirectX", they're referring to pre-DX12. It certainly doesn't back up your claim that it's "much better" than Vulkan.
      - pandaman 10y ago
        What is the SRT equivalent in Vulkan if you don't mind me asking? What about DispatchDraw?
        Overv 10y ago
        Descriptor layouts are the equivalent of SRT in Vulkan. It is unclear to me what exactly DispatchDraw is for, because back-face and offscreen culling are standard features of any graphics pipeline.
        pandaman 10y ago
        >Descriptor layouts are the equivalent of SRT in Vulkan. I am not sure how. I do not use Vulkan, I use GNM. I asked this because implementing SRT does not seem possible in a platform independent API. So I checked the docs again and the descriptor layout is the same thing I remember - a set of bindings you manage through a bunch of API calls. On the other hand SRT is a plain c-structure. You pass a pointer to structure to a shader as a parameter. Exactly as same as you pass a structure to a function in C/C++. You don't need APIs to create sturctures, you can store them in a file, you can write them from another shader etc. etc. > It is unclear to me what exactly DispatchDraw is for, because back-face and offscreen culling are standard features of any graphics pipeline. It's pretty clear what is it for if you actually wrote real-time graphics. JFYI - it's "index shader" essentially. Having control over indices you can implement much faster culling.
        pcwalton 10y ago
  - bitbiter 10y ago
    Vulcan, DirectX 12, and Metal are basically like C. They're made to be as low level as possible while maintaining hardware portability. With the PS4 hardware is locked so their API is more like assembly (or maybe inline assembly in a C program) where you're doing specific hardware operations. They also provide a second graphics API that wraps that one, working basically at the same level as Direct3D 11 or OpenGL. This article might be of interest: http://www.eurogamer.net/articles/digitalfoundry-inside-playstation-4 http://www.eurogamer.net/articles/digitalfoundry-inside-play...
  - shmerl 10y ago
    It's not better, it's lower level than even Vulkan, and Vulkan itself is already very low level. Sure you can go as low as hardware specific machine code in theory. The question is whether it's something needed, or it's an overkill for most intents and purposes. Consoles had a distinct need for assembly like level APIs - their hardware had very long update cycle (7+ years), so it used to quickly become outdated, and developers had to go to insane lengths to squeeze performance out of it. It's not only very costly to do it, it can't be reused (it's all platform specific). Currently consoles are moving away from these long cycles (under competitive pressure), so need for that will be less as well.
    - zanny 10y ago
      There is also the fact that in modern CPU-side development you will find it almost always is a bad idea to try to drop to assembly micro-optimization. Your compiler is going to almost always do a better job optimizing the general case into an optimal set you won't be able to easily implement in raw ASM, especially when you start using vectorization instructions. The same concept applies to Vulkan / DX12. The hardware manufacturers will know better than any developers about per-device shortcuts to put into their drivers, and if they do not need to maintain millions of LOCs of OpenGL state machine and validation layers they might find time to optimize the shader compiler to be in the same class of "the compiler is smarter than you" reasons not to use a hard ASM language. In the case of consoles, all of them are using AMD based graphics, and when the next generation comes out they will all be on a similar cadence of GCN. I cannot imagine in what world an optimized AMD SPIR-V compiler that AMD already needs to write for the desktop and mobile won't beat 99% of developers on both the Sony / MS / Nintendo and 3rd party sides trying to microoptimize RadeonSI ASM.
      - shmerl 10y ago
        > I cannot imagine in what world an optimized AMD SPIR-V compiler that AMD already needs to write for the desktop and mobile won't beat 99% of developers on both the Sony / MS / Nintendo and 3rd party sides trying to microoptimize RadeonSI ASM. Good point. Today not to provide Vulkan on consoles is a political diversion (to make cross platform development more costly by taxing developers with doing the same thing multiple times).
- shmerl 10y ago
  > The PS4 API is already much better than Vulkan. It's like saying that assembly is better than higher level languages. So propose writing everything in assembly as the next step? Everything has its trade-offs.
  - pcwalton 10y ago
    We don't really have enough experience to compare GPU assembly vs. SPIR-V. For pjmlp's claim that the PS4 API is "much better" than Vulkan to hold up, as far as I can tell you'd have to show that the codegen (i.e. passes after IR-level optimizations) of the driver's SPIR-V compiler can't match what game developers regularly do. I'm doubtful (instruction scheduling, for example, is too much to keep in your head to regularly beat a compiler), and especially so without data.
    - shmerl 10y ago
      I'm also doubtful that developers can regularly beat optimizing compiler by a big margin. It's theoretically possible, but I'd expect it to be far from trivial, and as result require substantial effort every time it's needed. Hacker folklore: http://www.catb.org/jargon/html/story-of-mel.html http://www.catb.org/jargon/html/story-of-mel.html
      - maccard 10y ago
        I disagree. I regularly stomp all over the optimizing compiler, and it's not a massive amount of effort. It doesn't come for free though, and requires some upfront planning. The best way to think of it, IMHO is rather than thinking of "beating the compiler", think about working _with_ the compiler to help it do it's job. I don't always agree with what he says, but Mike Acton has some good words and examples of this. https://www.youtube.com/watch?v=GPpD4BBtA1Y https://www.youtube.com/watch?v=GPpD4BBtA1Y - a youtube talk where he talks about working with the compiler. The slides are at http://www.slideshare.net/cellperformance/gdc15-code-clinic http://www.slideshare.net/cellperformance/gdc15-code-clinic In particular take a look at slide 69 and the few following it for an example of things the compiler can't figure out (for various reasons) that we can help it along with.
- SeanDav 10y ago
  How well does the PS4 API work on Windows, Linux and Android? That is kind of the point of Vulcan.

Vulkan could very well be a different story, it doesn't have OpenGL's shortcomings.

by vardump 10y ago

Vulkan could very well be a different story, it doesn't have OpenGL's shortcomings.

pjmlp 10y ago

The PS4 API is already much better than Vulkan.

vardump 10y ago
Except in portability.
- cobalt 10y ago
  given how tailored games are already anyway, as well as wanting to be as low level as possible, that wont really matter
  - vardump 10y ago
    Vulkan is pretty close to "as low level as possible". If it's available, it'll certainly be a tempting target for those who have lower budget and those who need to port it faster.
pcwalton 10y ago
Can you describe how, specifically?
- pjmlp 10y ago
  Here is a NDA free presentation I can point to. http://develop.scee.net/wp-content/uploads/2014/11/ParisGC2013Final.pdf http://develop.scee.net/wp-content/uploads/2014/11/ParisGC20... Starts on slide 32 for the graphics part.
  - pcwalton 10y ago
    As I suspected, all of the features that I can see described here are in Vulkan. In particular, the first couple of slides pretty much identically resemble Vulkan's "elevator pitch". The presentation is from 2014, so when they claim "better than DirectX", they're referring to pre-DX12. It certainly doesn't back up your claim that it's "much better" than Vulkan.
    - pandaman 10y ago
      What is the SRT equivalent in Vulkan if you don't mind me asking? What about DispatchDraw?
      - Overv 10y ago
        Descriptor layouts are the equivalent of SRT in Vulkan. It is unclear to me what exactly DispatchDraw is for, because back-face and offscreen culling are standard features of any graphics pipeline.
        pandaman 10y ago
        >Descriptor layouts are the equivalent of SRT in Vulkan. I am not sure how. I do not use Vulkan, I use GNM. I asked this because implementing SRT does not seem possible in a platform independent API. So I checked the docs again and the descriptor layout is the same thing I remember - a set of bindings you manage through a bunch of API calls. On the other hand SRT is a plain c-structure. You pass a pointer to structure to a shader as a parameter. Exactly as same as you pass a structure to a function in C/C++. You don't need APIs to create sturctures, you can store them in a file, you can write them from another shader etc. etc. > It is unclear to me what exactly DispatchDraw is for, because back-face and offscreen culling are standard features of any graphics pipeline. It's pretty clear what is it for if you actually wrote real-time graphics. JFYI - it's "index shader" essentially. Having control over indices you can implement much faster culling.
        pcwalton 10y ago
- bitbiter 10y ago
  Vulcan, DirectX 12, and Metal are basically like C. They're made to be as low level as possible while maintaining hardware portability. With the PS4 hardware is locked so their API is more like assembly (or maybe inline assembly in a C program) where you're doing specific hardware operations. They also provide a second graphics API that wraps that one, working basically at the same level as Direct3D 11 or OpenGL. This article might be of interest: http://www.eurogamer.net/articles/digitalfoundry-inside-playstation-4 http://www.eurogamer.net/articles/digitalfoundry-inside-play...
- shmerl 10y ago
  It's not better, it's lower level than even Vulkan, and Vulkan itself is already very low level. Sure you can go as low as hardware specific machine code in theory. The question is whether it's something needed, or it's an overkill for most intents and purposes. Consoles had a distinct need for assembly like level APIs - their hardware had very long update cycle (7+ years), so it used to quickly become outdated, and developers had to go to insane lengths to squeeze performance out of it. It's not only very costly to do it, it can't be reused (it's all platform specific). Currently consoles are moving away from these long cycles (under competitive pressure), so need for that will be less as well.
  - zanny 10y ago
    There is also the fact that in modern CPU-side development you will find it almost always is a bad idea to try to drop to assembly micro-optimization. Your compiler is going to almost always do a better job optimizing the general case into an optimal set you won't be able to easily implement in raw ASM, especially when you start using vectorization instructions. The same concept applies to Vulkan / DX12. The hardware manufacturers will know better than any developers about per-device shortcuts to put into their drivers, and if they do not need to maintain millions of LOCs of OpenGL state machine and validation layers they might find time to optimize the shader compiler to be in the same class of "the compiler is smarter than you" reasons not to use a hard ASM language. In the case of consoles, all of them are using AMD based graphics, and when the next generation comes out they will all be on a similar cadence of GCN. I cannot imagine in what world an optimized AMD SPIR-V compiler that AMD already needs to write for the desktop and mobile won't beat 99% of developers on both the Sony / MS / Nintendo and 3rd party sides trying to microoptimize RadeonSI ASM.
    - shmerl 10y ago
      > I cannot imagine in what world an optimized AMD SPIR-V compiler that AMD already needs to write for the desktop and mobile won't beat 99% of developers on both the Sony / MS / Nintendo and 3rd party sides trying to microoptimize RadeonSI ASM. Good point. Today not to provide Vulkan on consoles is a political diversion (to make cross platform development more costly by taxing developers with doing the same thing multiple times).
shmerl 10y ago
> The PS4 API is already much better than Vulkan. It's like saying that assembly is better than higher level languages. So propose writing everything in assembly as the next step? Everything has its trade-offs.
- pcwalton 10y ago
  We don't really have enough experience to compare GPU assembly vs. SPIR-V. For pjmlp's claim that the PS4 API is "much better" than Vulkan to hold up, as far as I can tell you'd have to show that the codegen (i.e. passes after IR-level optimizations) of the driver's SPIR-V compiler can't match what game developers regularly do. I'm doubtful (instruction scheduling, for example, is too much to keep in your head to regularly beat a compiler), and especially so without data.
  - shmerl 10y ago
    I'm also doubtful that developers can regularly beat optimizing compiler by a big margin. It's theoretically possible, but I'd expect it to be far from trivial, and as result require substantial effort every time it's needed. Hacker folklore: http://www.catb.org/jargon/html/story-of-mel.html http://www.catb.org/jargon/html/story-of-mel.html
    - maccard 10y ago
      I disagree. I regularly stomp all over the optimizing compiler, and it's not a massive amount of effort. It doesn't come for free though, and requires some upfront planning. The best way to think of it, IMHO is rather than thinking of "beating the compiler", think about working _with_ the compiler to help it do it's job. I don't always agree with what he says, but Mike Acton has some good words and examples of this. https://www.youtube.com/watch?v=GPpD4BBtA1Y https://www.youtube.com/watch?v=GPpD4BBtA1Y - a youtube talk where he talks about working with the compiler. The slides are at http://www.slideshare.net/cellperformance/gdc15-code-clinic http://www.slideshare.net/cellperformance/gdc15-code-clinic In particular take a look at slide 69 and the few following it for an example of things the compiler can't figure out (for various reasons) that we can help it along with.
SeanDav 10y ago
How well does the PS4 API work on Windows, Linux and Android? That is kind of the point of Vulcan.