Blumenkrantz Back To Working On Zink Improvements For 2023

[geearf]

Well they can always use OpenGL then, I mean older GPU's do have OpenGL support because that is what was mainly used when they were created and this will likely not be removed. Pretty much every new mainstream GPU will have Vulkan support so thats going to be a non issue.

Right, but software also needs to be usable only with OGL hardware support, at least in the forsable future.

You also have to look at what happened in the Windows landscape, for example Direct3D has been removed and/or replaced with a software renderer which means a few older games either don't work or are very slow. There are however open source/community made Direct3D drivers which are implemented with newer API's (i.e. DirectX/Vulkan) and since we are dealing with Windows you can just place the dll of the new driver in the root game directory and it will automatically be picked up (I have been doing this with Red Alert 2)

Which D3Ds are these? Before 8?
I'm all for these kind of libraries, but it needs to work with GPUs that don't support Vulkan... It'd be nice if we could have some lighter Vulkan that would be supported by much older GPUs, if only for the purpose of being able to run these libraries.

[mdedetrich]

Right, but software also needs to be usable only with OGL hardware support, at least in the forsable future.

True, but I see no effort in removing such support. What will likely happen is that older OGL drivers will be used in the case of the card not supporting Vulkan

Which D3Ds are these? Before 8?
I'm all for these kind of libraries, but it needs to work with GPUs that don't support Vulkan... It'd be nice if we could have some lighter Vulkan that would be supported by much older GPUs, if only for the purpose of being able to run these libraries.

Well this is Windows specific, but there are OS drivers that also use OGL as a backend

[ehansin]

What about the GPUs that don't support Vulkan?

I'll be honest, I am not knowledgeable enough in this space to know how things could best be handled. I am not saying mdedetrich is correct (nor am I saying he is not, I am not an expert), but conversations around the issue can at least help sort out what may and may not work.

I do remember reading here in the past that one nice thing for going forward is that new GPU designs would just need to have a Vulkan driver and than Zink would allow these GPUs to run OpenGL applications without actually needing a proper GPU specific driver. I think I also read that there are some quirks and inconsistencies between the various current OpenGL implementations that can need workarounds, and that Zink could be a sort of "de-facto known entity" implementation. Someone can correct me if I am wrong her, but thought I read this once.

Anyway, anytime you have to "cross the chasm" into a "new world:, these things need to be sorted out. I'm not saying this is always done the best way or whatever, but if you want to move forward from being stuck in legacy cruft, you need to pave a path to get there.

[geearf]

I'll be honest, I am not knowledgeable enough in this space to know how things could best be handled. I am not saying mdedetrich is correct (nor am I saying he is not, I am not an expert), but conversations around the issue can at least help sort out what may and may not work.

I do remember reading here in the past that one nice thing for going forward is that new GPU designs would just need to have a Vulkan driver and than Zink would allow these GPUs to run OpenGL applications without actually needing a proper GPU specific driver. I think I also read that there are some quirks and inconsistencies between the various current OpenGL implementations that can need workarounds, and that Zink could be a sort of "de-facto known entity" implementation. Someone can correct me if I am wrong her, but thought I read this once.

Anyway, anytime you have to "cross the chasm" into a "new world:, these things need to be sorted out. I'm not saying this is always done the best way or whatever, but if you want to move forward from being stuck in legacy cruft, you need to pave a path to get there.

Yeah you're correct, and that could be great for legacy apps and for future GPUs, no need to keep on writing OGL drivers.

[Amaranth]

Right, but software also needs to be usable only with OGL hardware support, at least in the forsable future.

Every desktop GPU released since 2012 supports Vulkan, although for Intel iGPUs anything before 2014 is a bit shaky. Things are less straightforward on mobile but every Android phone released since 2019 has to support it and many did since 2017. Outside of Android ARM Mali has supported it since 2013 and Qualcomm Adreno since 2015 (2016 on the low end parts).

Unless I was writing something meant for mobile I would have no problem deciding to just use Vulkan. At some point you have to be willing to drop support for older hardware and embrace new technologies and I think over a decade is plenty of time to wait. For mobile I'd likely do so as well but that would depend on the performance level the application needs, anything old enough to not have Vulkan may be too slow to be usable there anyway.

[geearf]

Every desktop GPU released since 2012 supports Vulkan, although for Intel iGPUs anything before 2014 is a bit shaky. Things are less straightforward on mobile but every Android phone released since 2019 has to support it and many did since 2017. Outside of Android ARM Mali has supported it since 2013 and Qualcomm Adreno since 2015 (2016 on the low end parts).

Unless I was writing something meant for mobile I would have no problem deciding to just use Vulkan. At some point you have to be willing to drop support for older hardware and embrace new technologies and I think over a decade is plenty of time to wait. For mobile I'd likely do so as well but that would depend on the performance level the application needs, anything old enough to not have Vulkan may be too slow to be usable there anyway.

I agree that if it's too weak to perform correctly then it does not matter, but if you were to write say a new compositor or something else that does not need a powerful GPU it'd be not great to not have it work with high end TeraScale models (and maybe even mid end).

[wertigon]

I agree that if it's too weak to perform correctly then it does not matter, but if you were to write say a new compositor or something else that does not need a powerful GPU it'd be not great to not have it work with high end TeraScale models (and maybe even mid end).

This argument assumes a low power OpenGL GPU draws less power than a low power Vulkan GPU. Since Vulkan is a much simpler technology it is much more likely Vulkan is the more power efficient chip.

OpenGL was and still is a good 3D API. Vulkan is just better in pretty much all respects. Good does not trump excellent.

As for Zink itself, the biggest impact it has is that it now is possible to build a Vulkan conformant hardware, build a small kernel module with only Vulkan calls, and then enjoy the rest of the stack om Linux Mesa. Making a GPU from scratch just got a whole lot easier.

[Developer12]

This argument assumes a low power OpenGL GPU draws less power than a low power Vulkan GPU. Since Vulkan is a much simpler technology it is much more likely Vulkan is the more power efficient chip.

OpenGL was and still is a good 3D API. Vulkan is just better in pretty much all respects. Good does not trump excellent.

As for Zink itself, the biggest impact it has is that it now is possible to build a Vulkan conformant hardware, build a small kernel module with only Vulkan calls, and then enjoy the rest of the stack om Linux Mesa. Making a GPU from scratch just got a whole lot easier.

The biggest issue is that there are a lot of AMD GPUs out there that do not support vulkan. Making vulkan mandatory regresses them. *Maybe* it's possible to support vulkan on *some* later-gen terascale architectures, at reduced performance, but that support has not yet materialized.

[wertigon]

The biggest issue is that there are a lot of AMD GPUs out there that do not support vulkan. Making vulkan mandatory regresses them. *Maybe* it's possible to support vulkan on *some* later-gen terascale architectures, at reduced performance, but that support has not yet materialized.

Yes. The last card with Terascale architecture was released 03-04-2014 as Radeon R5 230. This was replaced by the R5 330 in May 2015. Let's assume another year for stocks to sell out, this means around Q2 2016, all Radeon GPUs sold since then was Vulkan capable. That is almost 7 years ago now.

Last Intel circuit was Iris 6200 released in Q2 2015, with the same logic last device sold with it should've been around 6 years ago.

As for Nvidia, they are not using Mesa and not interested in using Mesa, instead going with their own homebrewed solution. So not relevant.

[Developer12]

Yes. The last card with Terascale architecture was released 03-04-2014 as Radeon R5 230. This was replaced by the R5 330 in May 2015. Let's assume another year for stocks to sell out, this means around Q2 2016, all Radeon GPUs sold since then was Vulkan capable. That is almost 7 years ago now.

Last Intel circuit was Iris 6200 released in Q2 2015, with the same logic last device sold with it should've been around 6 years ago.

As for Nvidia, they are not using Mesa and not interested in using Mesa, instead going with their own homebrewed solution. So not relevant.

I'm not talking about video cards. Laptops and their chips tend to stick around a lot longer. I happen to be writing this from a terascale3 APU.

A similar concern came up with the deprecation of midguard from panVK: https://gitlab.freedesktop.org/mesa/...requests/16915

There is a risk here: in the future, 2D workloads (like desktop compositors) might hard depend on Vulkan. It seems this is bound to happen but about a decade out. I worry about contributing to hardware obsolescence due to missing Vulkan drivers, however such a change would obsolete far more than Midgard v5... There's plenty of GL2 hardware that's still alive and well, for one. It doesn't look like Utgard will be going anywhere, even then.