[Mesa-dev] radv initial submission
airlied at gmail.com
Tue Oct 4 22:45:17 UTC 2016
On 4 October 2016 at 20:47, Albert Freeman <albertwdfreeman at gmail.com> wrote:
> It might be a good idea to consider moving the nir -> llvm code out of
> the amd folder for reuse by a Vulkan software rasterizer or something.
> I have heard another developers recent interest in developing a Vulkan
> software rasterizer. I at one stage was interested in developing a
> Vulkan software rasterizer but ended up just buying a computer with
> hardware Vulkan support. These days I am focused more towards
> compositors and other just above gpu driver stuff (esp. since
> everything in mesa looks to be going smoothly with the current
> developers except for OpenCL and not as many driver tweaking options
> as there could be and lack of visually attractive guis for that and
> Nvidia and other drivers etc). Of course some of the nir -> llvm code
> is for radeons (meaning it takes a bit of effort to move out) and it
> could be a while before a Vulkan software rasterizer is developed and
> it might not even use llvm (but use of llvm does seem likely).
I don't think the nir->llvm code it that splittable, it uses a lot of
intrinsics, until a second user shows up who isn't me I doubt it's worth it
> The Vulkan drivers are missing out on the gallium HUD and postprocess
> from a users perspective. But gallium-less does help with stepping
> through Vulkan drivers in a debugger. And perhaps makes it easier to
> understand the driver.
These things would be implemented as Vulkan layers outside the scope
of the drivers. For the HUD we'd have to add some query APIs to Vulkan
for the HUD rendering layer to use but that wouldn't be too crazy a job.
The main problem I forsee with vulkan layers is that, it's someone else's
job to do that so nobody will ever do it.
More information about the mesa-dev