On Thu, Nov 16, 2017 at 12:33 AM, Dave Airlie <airl...@gmail.com> wrote: > On 15 November 2017 at 04:40, Jason Ekstrand <ja...@jlekstrand.net> wrote: >> This commit significantly reworks the way prime support works and lets >> us pull it even further into radv. The old mechanism required the >> specific WSI layer to be aware of the linear shadow copy that has to be >> done in order for prime to work. In the new paradigm, we better define >> what bits of wsi_image go to the client and what bits go off to the >> window system. It's then the job of the driver to allocate two separate >> images and stash whatever intermediates it needs in driver_private. >> There are a few advantages to this method: >> >> 1) It separates supporting prime from the driver decision as to whether >> it's better to render directly into the window-system-compatible >> image or if it's better to blit. >> >> 2) Because of this separation, it's now possible for a driver to use a >> different scheme for WSI image presentation where it hooks the >> vkCmdPipelineBarrier that transitions the image to >> VK_IMAGE_LAYOUT_PRESENT_SRC_KHR and does the blit there. >> >> 3) It lets us pull more of the details into radv and, in my opinion, >> actually makes the radv code more straightforward. > > For the record, PRIME is not radv specific, stop trying to make it so, > anv should support display to other GPUs.
Yes it would be great if that worked, would make radv vs anv testing so much easier as I much prefer my display to be on dGPU. GraÅžvydas _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
