Mir Continues Cleaning Up Their OpenGL Code, To Support Vulkan In Future

[phoronix]

Phoronix: Mir Continues Cleaning Up Their OpenGL Code, To Support Vulkan In Future

Since this summer we've known that Canonical developers have been looking at Vulkan in regards to supporting this forthcoming graphics API by Unity 8 and Mir. Since then we've seen work done in Mir to support renderers other than OpenGL with this Ubuntu display server. As another sign of working towards Vulkan, more of Mir's OpenGL code continues to be re-factored...

http://www.phoronix.com/scan.php?page=news_item&px=Mir-OpenGL-Changes-For-V

[dh04000]

I'm not sure WHY Mir/Wayland even need to support Vulkan......? Isn't Vulkan for low level stuff? Games will use OpenGL/Vulkan/(Insert Future Thing) independently of the desktop, and what the desktop uses has ZERO effect on games and other graphically applications. OpenGL is hear to stay AFAIK, so why does Mir/Wayland want to support Vulkan?

I feel like this is a developer driven obsession with having the BEST technology, with little consideration of how little effect this will have on the user.

[Kemosabe]

I'm not sure WHY Mir/Wayland even need to support Vulkan......? Isn't Vulkan for low level stuff? Games will use OpenGL/Vulkan/(Insert Future Thing) independently of the desktop, and what the desktop uses has ZERO effect on games and other graphically applications. OpenGL is hear to stay AFAIK, so why does Mir/Wayland want to support Vulkan?

I feel like this is a developer driven obsession with having the BEST technology, with little consideration of how little effect this will have on the user.

I am quite sure Mir != Wayland and the article talks about Mir. Mir supporting Vulkan *and other APIs* is a really smart move IMHO since it allows to get the best out of each supported platform. More than that everybody expects Vulkan to be superior the OpenGL in almost every aspect (expect ease to use). Don't you think you will find an article on phoronix benchmarking Mir vs Wayland wit Mir delivering slightly better performance? And lower resource usage of the desktop environment will of course affect the performance of the applications running besides it.

[justmy2cents]

I'm not sure WHY Mir/Wayland even need to support Vulkan......? Isn't Vulkan for low level stuff? Games will use OpenGL/Vulkan/(Insert Future Thing) independently of the desktop, and what the desktop uses has ZERO effect on games and other graphically applications. OpenGL is hear to stay AFAIK, so why does Mir/Wayland want to support Vulkan?

I feel like this is a developer driven obsession with having the BEST technology, with little consideration of how little effect this will have on the user.

at least the WSI is needed to be supported by them. another thing i see that they might adopt is common interchange format.

you must look at Vulkan for what it is, not just low level API. while low level API is one of biggest things Vulkan has it going, second much bigger thing than that is not so obvious than the first one. one of best things that i can see is design on how it works, where it is bound by strict rules from every side.

- it has common loader (solves big problem in OpenGL)
- shaders only accept SPIR-V which not only solves the GLSL problems (no binary format, compiler differences between vendors... blahblah), but also solves the validation. if shader cannot be reproduced in SPIR-V it cannot be passed to Vulkan at all and this solves everything that was wrong with GLSL
- common interchange format unifies in how data (and which) is passed to vulkan
- WSI solves interaction with displays (which is again sore topic in OpenGL), where developer should not care if he is working on Wayland, Mir, Windows...
...

and the more you look the Vulkan infrastructure, the more you see how this bounding box is much more important than Vulkan it self as one of the effects it brings is the fact that Vulkan low level API can be simpler and better defined.

[JS987]

I'm not sure WHY Mir/Wayland even need to support Vulkan......? Isn't Vulkan for low level stuff? Games will use OpenGL/Vulkan/(Insert Future Thing) independently of the desktop, and what the desktop uses has ZERO effect on games and other graphically applications. OpenGL is hear to stay AFAIK, so why does Mir/Wayland want to support Vulkan?

OpenGL has high CPU overhead which can cause high CPU usage by Mir/Wayland which will slow down applications.

[bregma]

Yes, like any sane successful application that needs to use the GPU in an efficient and effective way, Mir will be using Vulkan where appropriate. The only newsworthy thing would be if it wasn't.

[giucam]

I'm not sure WHY Mir/Wayland even need to support Vulkan......? Isn't Vulkan for low level stuff? Games will use OpenGL/Vulkan/(Insert Future Thing) independently of the desktop, and what the desktop uses has ZERO effect on games and other graphically applications. OpenGL is hear to stay AFAIK, so why does Mir/Wayland want to support Vulkan?

I feel like this is a developer driven obsession with having the BEST technology, with little consideration of how little effect this will have on the user.

Mir and wayland compositors don't *need* to use vulkan for rendering, but they need to support vulkan buffers from the applications, otherwise they won't show up on screen.

[mdias]

OpenGL has high CPU overhead which can cause high CPU usage by Mir/Wayland which will slow down applications.

Not really. OpengL has high CPU overhead for game-related stuff, like tons of draw calls, tons of shaders/material switching and so on. You would be hard pressed to reach a point where OpenGL gets to be the bottleneck in a compositor...

I do however support the API abstraction layer as it will mean cleaner code and easier maintenance. You shouldn't expect noticable performance gains from switching from OGL to Vulkan (or any other) in a compositor.

[JS987]

Not really. OpengL has high CPU overhead for game-related stuff, like tons of draw calls, tons of shaders/material switching and so on. You would be hard pressed to reach a point where OpenGL gets to be the bottleneck in a compositor...

If compositor has e.g. 5% CPU usage instead of 20%, more CPU time can be used be used by applications which is important on e.g. CPUs with less than 10 W TDP.

[blackout23]

If compositor has e.g. 5% CPU usage instead of 20%, more CPU time can be used be used by applications which is important on e.g. CPUs with less than 10 W TDP.

Too bad that the CPU usage of a Vulkan compositor would be the same as an OpenGL compositor. Using Vulkan doesn't automatically lead to lower CPU usage everywhere you use it in all scenarios. Stop making shit up.