GTK 4 has been released. Does Purism team have plans with it?

I plan to backport GTK4 into Byzantium as soon as GTK 4.2 (or later) enters Debian unstable/experimental (unless someone else beats me to it)

10 Likes

Yesterday on Byzantium i got Calculator version 40, it seems that Librem 5 already has GTK4 support…
@dos can you confirm this please.?

GNOME Calculator 40 still uses GTK3. GTK4 is coming to byzantium soon (https://source.puri.sm/Librem5/debs/gtk4), but it’s unrelated to Calculator :wink:

6 Likes

OK. Thanks for your fantastic work @dos .

That is great news!
What I find a bit unfortunate though is that while gtk4 supports hardware acceleration using Vulkan as backend and the Vivante GPU in Librem 5 is capable of supporting Vulkan 1.0, there is currently no plan or resources being put into the Etnaviv driver to make this a reality. I’m a bit surprised that support for Vulkan is not a higher priority according to the “fund your app” page:

https://puri.sm/fund-your-app/

There is actually a category “graphics acceleration” in the “software optimization” section at the very end of that page, but I don’t think it has received much attention from donators unfortunately. Having a Vulkan capable driver for the Vivante GPU in Librem 5 would enable great performance for gtk4 apps and also games. Furthermore, having a Vulkan driver would automatically add support for Open GL ES 3.2 by the means of the Zink driver (Open GL over Vulkan) :

https://www.phoronix.com/scan.php?page=news_item&px=Zink-OpenGL-ES-3.2

It would even enable desktop Open GL. :blush:.

I do realize though that developing a Vulkan driver for the Vivante GPU is a huge endeavor that few developers have the skill to pull through, but I can’t help but feel that it’s a shame to have a GPU that is not utilized to its fullest.

Update: Just donated 25$ to “graphics acceleration”, specifically mentioning a Vulkan driver for the Vivante GPU through the means of the Etnaviv Mesa driver project. :blush:

5 Likes

I think that collabora.com it may surprise for vulcan support to Librem 5 GPU.
Recently Collabora added support for AVC/HEVC to Linux kernel driver benefiting to L5.

1 Like

Well that would be really great.
I know Collabora have a very talented intern by the name Alyssa Rosenzweig

https://rosenzweig.io/

who is the main developer behind the Panfrost GPU driver for Mali GPU cores from ARM, specifically Midgard and Bifrost:

Purism should just send her a Librem 5 and perhaps magical stuff would happen after some time. :wink:.
Or they should contract her to work on a Vulkan driver for the Librem 5.

Edit: Apparently Collabora has now also started working on a Vulkan driver for ARM Mali Midgard and Bifrost GPUs:

3 Likes

Very very interesting. If Librem 5 get support Vulcan it get good traction, like Super Smooth and Super Fast GTK4 apps & ecosystem, Low Energy overall, nice Graphics Games.

  • Purism team need to getting touch with Alyssa Rosenzweig to found a way to support Vulcan.
  • Librem 5 user maybe crowdfunding some money to Alyssa Rosenzweig to work on Vulcan to L5.
1 Like

Perhaps customers are funding more tangible, easier to understand and see things, like specific apps and applications.

Yes, I get that.
It’s just that while adapting a current application to run nicely on the Librem 5 may take a couple of months, developing a Vulkan driver will take a year, at least. And if the work is never initiated, you are just pushing that date further away. So if someone starts developing a Vulkan driver in 6 months we are talking about having support for Vulkan in 1,5 years and so on. Perhaps we will never have it because the work will never be initiated. And that is unfortunate. It’s like buying a sports car only to find out that the performance of the engine is capped so you can only cruise at low speed. :blush:.

I like @carlosgonz suggestion:

  • Purism should start by sending a couple of Librem 5 units to prolific Mesa developers, like Alyssa Rosenzweig.

  • Explicitly mention Vulkan driver as funding goal and explain what it would mean: accelerated gtk4, better 3d support (games, other applications like Blender?).

  • If the funding goal is reached, contract Alyssa or some other Mesa developer to start working on this.

3 Likes

… and if Purism does not have any plan for developing a Vulkan driver in the near future (read: within the next couple of years), they should be more clear about this limitation when listing the specification for the phone.
For example, when announcing the final specifications for the Librem 5 back in 2019, Vulkan was specifically mentioned for the GPU:

  • GPU: Vivante GC7000Lite (hardware supports OpenGL/ES 3.1, Vulkan, OpenCL 1.2)

Now, I realize it’s formally not incorrect to specify that the GPU is technically capable of supporting Vulkan. But I would say it’s a bit misleading if you don’t intent to actually develop a driver to support it. It’s a bit like selling a Tesla that you specify having some feature, but when you buy the car and notice it does not work you are told that the hardware is in the car but no software has been developed to support it yet. Furthermore, there is not even a plan nor a timeline for when this will happen, if ever. :blush:.

Of the list of priorities that Purism has on its plate, I would place Vulkan support as a low priority. It would divert Purism’s scarce resources from more important projects in my opinion, if Purism decided to invest in the development of a Vulkan driver for Vivante GPUs.

First of all, Collabora only made the initial announcement that it would start developing the PanVK driver to provide Vulkan support to Mali GPUs on March 25, 2021 and there have been no commits to the driver since May 6. Maybe development moved to a different location or maybe Collabora has decided to put the project on hold. Given the pace of Mesa development in general, I would guesstimate that 2-3 years is more realistic than 1 year before we will see working Vulkan support for any mobile processors in Linux.

Unlike the Mali and Adreno mobile GPUs which are widely used, Vivante’s GPUs are not used in many devices, and it is going to be much harder to convince companies and volunteers to work on an Etnaviv Vulkan driver. Collabora has 103 employees (almost all software developers) and it is a firm with a lot of experience in this kind of dev work, whereas Purism doesn’t have anyone on staff with this kind of experience, so it would have to hire additional developers with experience to work on adding Vulkan to Etnaviv.

Currently Purism is paying 11 software devs to work on the Librem 5 (according to its Team page) and it appears to me that Purism has financial problems which is why it changed its refund policy, had to cut back on the number of L5 developers (which were 15 at the beginning of 2020), and decided to only develop one new laptop model instead of two. In other words, you are saying that Purism should stop paying a couple of its current developers, so it can hire some others to work on a Vulkan driver that probably won’t be ready for a couple years.

Which developers do you propose that Purism stop paying and which projects should be dropped or delayed in order to pay for Vulkan drivers for Vivante GPUs? Squeakboard? Megapixels/V4L2? Fractal? libhandy/libadwaita? phoc/phosh? smartcard driver and OpenPGP integration with apps? Adapting GNOME apps to use libadwaita? work on suspend?

In my opinion, Purism’s highest priority should be to get get a working Linux phone, and diverting funds to pay for Vulkan development is only going to delay the Librem 5 even more. Maybe Purism can find volunteers to work on Volkan for Vivante GPUs, but I doubt it, and frankly developing Phosh and libadwaita is far more important for the future of mobile Linux than Vulkan support, and will benefit far more people as well.

Which developers do you propose that Purism stop paying and which projects should be dropped or delayed in order to pay for Vulkan drivers for Vivante GPUs?

None. My proposal was

  1. Purism should give away a couple of Librem 5 devices to prolific Mesa developers. If they can afford to send samples to Tech bloggers, which they have, then surely they can afford to give away few samples to Mesa developers? Unlike tech bloggers, giving away a few samples to key developers within the Linux community has the chance to actually speed up and broaden the development for the Librem 5.

  2. Specifically mention development of a Vulkan driver for the Vivante GPU as a fund raising goal. If enough people care about this then there is at least a chance that a driver may be developed.

And as I said, if there is no intention nor a timeline nor a goal to eventually develop a Vulkan driver for the GPU in Librem 5, then Purism should clearly state this. Because right now it is misleading. What is the point of even mentioning Vulkan for the specification if there are no plans to support it? Better to not mention it at all then.

2 Likes

Is there a current non-free driver available for the GPU that can be used in the meantime? I know Purism would never provide/promote this but for the performance increase I would roll with it.

I assume that the proprietary imx-gpu-viv6.4.3.p2.0-aarch64.bin driver in NXP’s L5.10.35_2.0.0_MX8MQ release for the i.MX 8M ​has Vulkan support, but I don’t know how to test it, since I can’t even download it (I don’t have an email account that NXP will accept). Maybe someone else can download it and post the file (which is technically piracy), so we can test it.

I’m skeptical that this will work, since Mesa volunteer developers who have the skill to do this kind of work are much more likely to focus their time on the PanVK driver, since there are billions of devices that have been sold with Mali GPUs. If you are a volunteer, why waste your time on GPU that is only used by a small number of devices? The logical thing to do would be to focus the development on the PanVK driver, and then later adapt it to work with Vivante and Adreno GPUs.

If we calculate how much it will cost to pay just one developer to work on this for a year, I don’t think this is a realistic option. Maybe Purism can apply for grant money (like it did for Julian Sparber to work on Fractal).

I agree that Purism should make it clear on its web page that the free/open source Etnaviv driver that comes with the L5 will only allow OpenGL 2.1 and OpenGL ES 2.0 support, and not Vulkan 1.0. By the way, work is advancing on OpenGL ES 3.0 support.

Given the pace of Mesa development in general, I would guesstimate that 2-3 years is more realistic than 1 year before we will see working Vulkan support for any mobile processors in Linux.

Perhaps it does not count as a “mobile processor” but the GPU for Raspberry Pie 4, the Broadcom VideoCore Vi, now supports Vulkan with Mesa driver:

Can also be seen looking at mesamatrix:

https://mesamatrix.net/

In fact, as can be seen, there is another ARM platform that supports Vulkan with Mesa and that is the Qualcomm “tu” as in Turnip driver. Also see here.

https://www.phoronix.com/scan.php?page=news_item&px=TURNIP-Vulkan-Tessellation

So of all GPUs targeting ARM, it’s only Vivante that does not have any development around Vulkan. Qualcomm and Broadcom both have Vulkan support and support for ARM Mali is at least initiated.

2 Likes

GTK4 is accelerated already with GL/GLES, and Blender doesn’t even have Vulkan support (yet). Also, Etnaviv devs (some have received their Librem 5 long time ago, FWIW) already expressed their interest in working on Vulkan support eventually, but it’s definitely a long-term goal and not something to hold your breath for. At this point I’d say GLES 3.0 support would be much more beneficial to the platform than redirecting efforts towards Vulkan.

5 Likes

Also, Etnaviv devs (some have received their Librem 5 long time ago, FWIW) already expressed their interest in working on Vulkan support eventually, but it’s definitely a long-term goal and not something to hold your breath for. At this point I’d say GLES 3.0 support would be much more beneficial to the platform than redirecting efforts towards Vulkan.

Thanks for letting us know.
Sounds great.

Also, Blender doesn’t use GTK at all.

There’s a new gtk4-rs repo for Rust, which I’m pretty excited about.