[Mesa-dev] radv initial submission

[Albert Freeman]

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).

Very nice work on the driver.


Some random notes about the linux graphics stack I don't know where
else to place (to no one in particular):

Of course Vulkan is currently lacking many of the useful extensions of
OpenGL which is probably going to delay applications (nobody quote me
on that). Which also makes me wonder how linux video is going to
integrate with Vulkan.

Although a shader assembler/disassembler would be useful.

Of course there are some major things that could be done in the
kernel: gpu schedulars (although it would help if there was better
hardware support (gpu hungry applications slow down the entire desktop
environment even on microsoft windows with amd drivers)), I am not
sure if the kernel dmas out discrete gpu memory to system memory on
sleep/hibernate (or keeps discrete memory powered during that time) (I
made a note of that a while ago so not sure if it still applies) and
of course prevent the drm from allowing "unprivileged" applications
from modifying/accessing gpu buffers (and state?) of other
applications.
I did also think about doing power-saving work in the kernel but
realised that is mostly under the control of the hardware devs. Of
course different shader optimizations might have a minor impact on
power saving. People do really seem to care about power usage of gpus
(esp. in laptops). I think this is more true of linux users than
windows ones (relative to gpu performance). Looking forward there will
be a lot more 3d environments (a lot of them battery powered) so it
will become even more important.

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.

On 4 October 2016 at 01:48, Dave Airlie <airlied at gmail.com> wrote:
> Hi all,
>
> I fully expect this won't make it to the list in one piece due to size.
> I've pushed the same patchset to
> https://github.com/airlied/mesa/tree/radv-submit
>
> This is an initial submission of the open source radv vulkan driver
> for AMD GPUs supported by the amdgpu driver. It is a project Bas and I
> started some months ago as an interesting learning experience and it's
> been great to see it get this far in such a short time.
>
> This driver is in no way to be considered conformant or called such.
> It has NOT passed the vulkan conformance suite or ever been submitted
> to Khronos. It prints a big warning on startup to this effect.
>
> In saying that, it runs quite well with Dota 2, Talos Principle and
> vkQuake in our testing so far.
>
> Future plans are to add support for various hw speedups (fast clears),
> missing things like spilling, and multiple queues along with finishing
> out things like geom/tess shaders. Also trying to reuse code between
> this and the radeonsi driver where possible. radv already reuses
> the LLVM compiler backend and the addrlib code.
>
> I've split things out into 4 patches, 3 just add code files to various
> places and number 4 intergrates the build system changes so they
> are easier to review.
>
> Regards,
> Dave (and on behalf of Bas).
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev