radv on Ubuntu broken in distro packages

It appears that Ubuntu mesa 17.2.2 packages that ship radv, have patches to enable MIR support. These patches actually just break radv instead. I'd seen some people complain that simple apps don't work on radv, and saying radv wasn't ready for use and how could anyone thing of using it and just wondered what they had been smoking as Fedora was working fine. Hopefully Canonical can sort that out ASAP.

Comments

  1. Fabio8 November 2017 at 00:52

    You can get working Vulkan drivers on Ubuntu with this PPA:
    https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers/

    ReplyDelete
  2. Marius Gedminas8 November 2017 at 02:47

    Do they know? https://bugs.launchpad.net/ubuntu/+source/mesa has only one bug mentioning radv, and it's not about radv.

    ReplyDelete
    Replies
    1. Fabio9 November 2017 at 00:19

      This is the Ubuntu bug:
      https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1720890

      Delete
  3. Lapo9 November 2017 at 16:03

    yes, they do: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1720890

    ReplyDelete

Post a Comment

Popular posts from this blog

radv takes over from AMDVLK

AMD have announced the end of the AMDVLK open driver in favour of focusing on radv for Linux use cases. When Bas and I started radv in 2016, AMD were promising their own Linux vulkan driver, which arrived in Dec 2017. At this point radv was already shipping in most Linux distros. AMD strategy of having AMDVLK was developed via over the wall open source releases from internal closed development was always going to be a second place option at that point. When Valve came on board and brought dedicated developer power to radv, and the aco compiler matured, there really was no point putting effort into using AMDVLK which was hard to package and impossible to contribute to meaningfully for external developers. radv is probably my proudest contribution to the Linux ecosystem, finally disproving years of idiots saying an open source driver could never compete with a vendor provided driver, now it is the vendor provided driver. I think we will miss the open source PAL repo as a reference sou...
Read more

fedora 43: bad mesa update oopsie

F43 picked up the two patches I created to fix a bunch of deadlocks on laptops reported in my previous blog posting. Turns out Vulkan layers have a subtle thing I missed, and I removed a line from the device select layer that would only matter if you have another layer, which happens under steam. The fedora update process caught this, but it still got published which was a mistake, need to probably give changes like this more karma thresholds. I've released a new update https://bodhi.fedoraproject.org/updates/FEDORA-2025-2f4ba7cd17  that hopefully fixes this. I'll keep an eye on the karma. 
Read more

a tale of vulkan/nouveau/nvk/zink/mutter + deadlocks

 I had a bug appear in my email recently which led me down a rabbit hole, and I'm going to share it for future people wondering why we can't have nice things. Bug: 1. Get an intel/nvidia (newer than Turing) laptop. 2. Log in to GNOME on Fedora 42/43  3. Hotplug a HDMI port that is connected to the NVIDIA GPU. 4. Desktop stops working. My initial reproduction got me a hung mutter process with a nice backtrace which pointed at the Vulkan Mesa device selection layer, trying to talk to the wayland compositor to ask it what the default device is. The problem was the process was the wayland compositor, and how was this ever supposed to work. The Vulkan device selection was called because zink called EnumeratePhysicalDevices, and zink was being loaded because we recently switched to it as the OpenGL driver for newer NVIDIA GPUs. I looked into zink and the device select layer code, and low and behold someone has hacked around this badly already, and probably wrongly and I've no ide...
Read more