[Mesa-dev] introducing radv - proof of concept vulkan driver for AMD VI chipsets
deathsimple at vodafone.de
Wed Jul 20 08:33:37 UTC 2016
Nice :) Not sure if that is going to fly but it at least adds some more
pressure on the issue of open sourcing AMDs internal vulkan implementation.
Am 19.07.2016 um 21:59 schrieb Dave Airlie:
> I was waiting for an open source driver to appear when I realised I
> should really just write one myself, some talking with Bas later, and
> we decided to see where we could get.
> This is the point at which we were willing to show it to others, it's
> not really a vulkan driver yet, so far it's a vulkan triangle demos
> It renders the tri and cube demos from the vulkan loader,
> and the triangle demo from Sascha Willems demos
> and the Vulkan CTS smoke tests (all 4 of them one of which draws a triangle).
> There is a lot of work to do, and it's at the stage where we are
> seeing if anyone else wants to join in at the start, before we make
> too many serious design decisions or take a path we really don't want
> So far it's only been run on Tonga and Fiji chips I think, we are
> hoping to support radeon kernel driver for SI/CIK at some point, but I
> think we need to get things a bit further on VI chips first.
> The code is currently here:
> There is a not-interesting branch which contains all the pre-history
> which might be useful for someone else bringing up a vulkan driver on
> other hardware.
> The code is pretty much based on the Intel anv driver, with the winsys
> ported from gallium driver,
> and most of the state setup from there. Bas wrote the code to connect
> NIR<->LLVM IR so we could reuse it in the future for SPIR-V in GL if
> required. It also copies AMD addrlib over, (this should be shared).
> Also we don't do SPIR-V->LLVM direct. We use NIR as it has the best
> chance for inter shader stage optimisations (vertex/fragment combined)
> which neither SPIR-V or LLVM handles for us, (nir doesn't do it yet
> but it can).
> If you want to submit bug reports, they will only be taken seriously
> if accompanied by working patches at this stage, and we've no plans to
> merge to master yet, but open to discussion on when we could do that
> and what would be required.
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
More information about the mesa-dev