No announcement yet.

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

  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by ElectricPrism View Post

    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.


    • #22
      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.
      Last edited by eddielinux; 08 October 2015, 02:24 PM.


      • #23
        Originally posted by gens View Post

        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


        • #24
          Originally posted by JS987 View Post
          GTK/Cairo/Qt would need to support GPU Rasterization using Vulkan similar to what is supported by Chrome

          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.


          • #25
            Originally posted by carewolf View Post
            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.
            Last edited by JS987; 09 October 2015, 01:47 PM.


            • #26
              Originally posted by Kemosabe View Post

              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.