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

[Kemosabe]

Forgive my assumptions please, however (...)

I forgive you and i really hope you can enjoy the illusion knowing something obvious everbody else does not know - here on this lovely Linux (oooops!) site.

[eddielinux]

For so many people the desktop is perfect as is, if it's good or bad I don't know, but sometimes we need go out of the box.
I think that we are not far from systems like Jarvis from Ironman movies and many others, can you imagine how many IOs is needed to make computer interact with us?
Maybe using a common HW with a new methodology can put us into a new level of interaction which can be very useful to medicine, nanomachines, chemistry, physics, geology and many other things (3d monitors with touch sensitivity?), for me vulkan can be the first step.

[justmy2cents]

you are bout bout right and wrong

vulkan will lead to lower cpu usage
the overhead of opengl in a compositor is very small

i have hit the cpu limit for opengl 3.3 with ~30k objects (same shader, same texture, etc., no instancing, times 2 for shadow map)
almost all of that is opengl validation
with some tricks (instancing and texture magic) 300k is not unrealistic (with opengl 4.4 it's absolutely do-able)

vulkan will also make much simpler drivers and can work without validation (by default), so less memory usage, less cache trashing and less cpu usage in general

note that all current window managers (compositing or not) are crap (i wrote a crap one myself) and wayland "shells" need to do much more then just put windows on screens

yea, thanks on pointing out other benefits i forgot validation. queue resubmitting is actually doing same and better job than instancing and other AZDO beneficial methods, but problem is that if there is not enough need, benefit will not be visible

although the point i was making that compositor that would work with noticeable resource usage would be bad compositor. and as soon as you try to calculate profit from 0 it won't be noticeable to user.

same as if you pissed your record amount of piss into the sea. you will feel proud, but no one will notice on global level

[carewolf]

GTK/Cairo/Qt would need to support GPU Rasterization using Vulkan similar to what is supported by Chrome
https://www.chromium.org/developers/...-rasterization

Qt has had that for years with the OpenGL paint-engine, the problem though is that normal paint-engine commands does not fit very well with OpenGL. Setting a pen and painting a line then changing the pen and drawing text, is perfectly fine with CPU rendering, but with a GPU it would be better to be batched. So while having such a back-end is neat, it is not really faster except for complex transforms.

[JS987]

Qt has had that for years with the OpenGL paint-engine

Redesign can be needed to match Vulkan API. Vulkan has command buffers for batching. It makes sense to use Vulkan if it will use less CPU time to render. CPU can be used for non-graphics processing while process is waiting for GPU.

[ElectricPrism]

I forgive you and i really hope you can enjoy the illusion knowing something obvious everbody else does not know - here on this lovely Linux (oooops!) site.

Now you're just adding insult to politeness. Shame on you sir.