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 <airl...@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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
