5 ms·

Why wouldn't an image editor need Vulkan? It's gotta render something somehow.

Narishma 7y ago
It just seems like an overkill and unnecessary requirement for a pixel editor. The first one I used ran just fine with software rendering on a 25Mhz CPU.
- chongli 7y ago
  It’s not about power, it’s about portability. As far as I’m aware there is no simple, low level, software based, portable, 2D graphics stack. The software you ran on a 25MHz machine was in all likelihood written in assembly, directly interfacing with the hardware of your machine, without even touching your windowing system (if you even had one, maybe you were running DOS). Modern operating systems frown on that sort of thing with extreme prejudice.
  - Narishma 7y ago
    I don't understand your comment. How is Vulkan more portable than a software renderer? And if you need hardware acceleration, OpenGL is more portable than Vulkan.
    - cloudhead 7y ago
      To chime in: it's not, but a software renderer wouldn't have the desired performance when rendering at the typical resolutions we see today (ie. up to 4K) - or would require a lot of work to get there.
      - pnako 7y ago
        We're talking about a pixel art editor here...
        feiss 7y ago
        Yeah, it's not a 3d game, but you still have to fill those 4k pixels...
    - tracker1 7y ago
      Today, it seems that Vulkan is really the most portable engine available. OpenGL support has kind of stagnated. I would have thought SDL is probably a better target for this type of application. However, I'm happy to see developers use what they like and push the envelope how they like. Just upgraded to Linux kernel 5.3 and beta mesa & vulkan so I can drop in my rx5700xt, which I still need to do.
      - ris 7y ago
        The problem is that vulkan was specifically designed to throw away an amount of portability in favour of allowing lower level access to hardware features. If said hardware features don't exist on a platform, you're stuck. Note the "The Vulkan Portable Subset" having to throw away a number of features to have it work on a number of underlying platforms https://www.khronos.org/vulkan/portability-initiative https://www.khronos.org/vulkan/portability-initiative . The advantage that opengl has is a number of software implementations that can be used as a last ditch on unsupported systems. Efforts for software vulkan implementations are taking a long time to appear.
  - twic 7y ago
    > As far as I’m aware there is no simple, low level, software based, portable, 2D graphics stack. Wasn't SDL supposed to be that? What happened to that?
    - chongli 7y ago
      SDL isn’t really simple or low level. You can use it to get an OpenGL context but its built-in 2D stack is very high level (and not very useful for a pixel editor).
- skohan 7y ago
  It would seem a bit counterproductive to me to use a software renderer when a graphics API will give you a ton of the desired functionality out of the box, and will have better performance characteristics.
  - Narishma 7y ago
    That would only be counterproductive if you actually need that functionality. Very few software would actually need what Vulkan offers. I can only think of AAA games.
    - skohan 7y ago
      What are you talking about? Shader languages are DSLs for working with images. Implementing a software renderer would require re-implementing many, many things you get for free when working with GLSL or HLSL. Vulkan is just an API for talking to graphics hardware. There are a wide variety of applications which can benefit from using it.
      - Narishma 7y ago
        My objection is about Vulkan specifically, not about using the GPU. It makes this software less portable than if they had used OpenGL, and for no benefit that I can see.
        grovesNL 7y ago
        rx uses wgpu-rs, which primarily supports Vulkan, Metal, and DX12 (though DX11 and GL backends are also partially supported). This is aready relatively portable compared to using GL directly, especially on macOS where it has been deprecated.
        skohan 7y ago
        I mean, your original comment specifically cited a software renderer, and your original objection was that vulkan was overkill, not that it wasn't well supported, so it seems like you're moving the goalposts all over the place but I'll bite. As someone who does graphics programming, I would not choose OpenGL for new projects. For one thing it's the future: while I only expect Vulkan to become more well supported as time goes on, the opposite is happening with OpenGL (see the state of support on Apple platforms). Also the Vulkan API itself actually makes it easier to target more platforms. Because the OpenGL api takes on more responsibility over how the graphics pipeline is executed, there is actually a lot more variation in behavior across driver implementations than you have with Vulkan. This was one of the biggest headaches of OpenGL development which Vulkan has largely solved. So if I had to choose between losing some users who are using old hardware verses the headaches of supporting an OpenGL application across platforms, along with the fact that OpenGL is actually getting less support over time, the choice would be easy for me. It's a moot point anyway since the developer here is already using a high-level compatibility library.
pnako 7y ago
It's like using PostgreSQL to save its config. But I don't want to criticize that choice. It looks like the author wrote something that worked for them, and more software should be like that (as counter-intuitive as it sounds).
- cloudhead 7y ago
  It's interesting to me that people think of Vulkan as a "heavy dependency", when it's actually the thinnest layer available between an application and the graphics card.

It just seems like an overkill and unnecessary requirement for a pixel editor. The first one I used ran just fine with software rendering on a 25Mhz CPU.

chongli 7y ago
It’s not about power, it’s about portability. As far as I’m aware there is no simple, low level, software based, portable, 2D graphics stack. The software you ran on a 25MHz machine was in all likelihood written in assembly, directly interfacing with the hardware of your machine, without even touching your windowing system (if you even had one, maybe you were running DOS). Modern operating systems frown on that sort of thing with extreme prejudice.
- Narishma 7y ago
  I don't understand your comment. How is Vulkan more portable than a software renderer? And if you need hardware acceleration, OpenGL is more portable than Vulkan.
  - cloudhead 7y ago
    To chime in: it's not, but a software renderer wouldn't have the desired performance when rendering at the typical resolutions we see today (ie. up to 4K) - or would require a lot of work to get there.
    - pnako 7y ago
      We're talking about a pixel art editor here...
      - feiss 7y ago
        Yeah, it's not a 3d game, but you still have to fill those 4k pixels...
  - tracker1 7y ago
    Today, it seems that Vulkan is really the most portable engine available. OpenGL support has kind of stagnated. I would have thought SDL is probably a better target for this type of application. However, I'm happy to see developers use what they like and push the envelope how they like. Just upgraded to Linux kernel 5.3 and beta mesa & vulkan so I can drop in my rx5700xt, which I still need to do.
    - ris 7y ago
      The problem is that vulkan was specifically designed to throw away an amount of portability in favour of allowing lower level access to hardware features. If said hardware features don't exist on a platform, you're stuck. Note the "The Vulkan Portable Subset" having to throw away a number of features to have it work on a number of underlying platforms https://www.khronos.org/vulkan/portability-initiative https://www.khronos.org/vulkan/portability-initiative . The advantage that opengl has is a number of software implementations that can be used as a last ditch on unsupported systems. Efforts for software vulkan implementations are taking a long time to appear.
- twic 7y ago
  > As far as I’m aware there is no simple, low level, software based, portable, 2D graphics stack. Wasn't SDL supposed to be that? What happened to that?
  - chongli 7y ago
    SDL isn’t really simple or low level. You can use it to get an OpenGL context but its built-in 2D stack is very high level (and not very useful for a pixel editor).
skohan 7y ago
It would seem a bit counterproductive to me to use a software renderer when a graphics API will give you a ton of the desired functionality out of the box, and will have better performance characteristics.
- Narishma 7y ago
  That would only be counterproductive if you actually need that functionality. Very few software would actually need what Vulkan offers. I can only think of AAA games.
  - skohan 7y ago
    What are you talking about? Shader languages are DSLs for working with images. Implementing a software renderer would require re-implementing many, many things you get for free when working with GLSL or HLSL. Vulkan is just an API for talking to graphics hardware. There are a wide variety of applications which can benefit from using it.
    - Narishma 7y ago
      My objection is about Vulkan specifically, not about using the GPU. It makes this software less portable than if they had used OpenGL, and for no benefit that I can see.
      - grovesNL 7y ago
        rx uses wgpu-rs, which primarily supports Vulkan, Metal, and DX12 (though DX11 and GL backends are also partially supported). This is aready relatively portable compared to using GL directly, especially on macOS where it has been deprecated.
      - skohan 7y ago
        I mean, your original comment specifically cited a software renderer, and your original objection was that vulkan was overkill, not that it wasn't well supported, so it seems like you're moving the goalposts all over the place but I'll bite. As someone who does graphics programming, I would not choose OpenGL for new projects. For one thing it's the future: while I only expect Vulkan to become more well supported as time goes on, the opposite is happening with OpenGL (see the state of support on Apple platforms). Also the Vulkan API itself actually makes it easier to target more platforms. Because the OpenGL api takes on more responsibility over how the graphics pipeline is executed, there is actually a lot more variation in behavior across driver implementations than you have with Vulkan. This was one of the biggest headaches of OpenGL development which Vulkan has largely solved. So if I had to choose between losing some users who are using old hardware verses the headaches of supporting an OpenGL application across platforms, along with the fact that OpenGL is actually getting less support over time, the choice would be easy for me. It's a moot point anyway since the developer here is already using a high-level compatibility library.

pnako 7y ago

It's like using PostgreSQL to save its config. But I don't want to criticize that choice. It looks like the author wrote something that worked for them, and more software should be like that (as counter-intuitive as it sounds).

cloudhead 7y ago
It's interesting to me that people think of Vulkan as a "heavy dependency", when it's actually the thinnest layer available between an application and the graphics card.