<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 16, 2017 at 3:47 AM, Mike Lothian <span dir="ltr"><<a href="mailto:mike@fireburn.co.uk" target="_blank">mike@fireburn.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Will this allow us to select between iGPU and dGPU like we can with OpenGL? Or is it just going to force radv like before?</div></blockquote><div><br></div><div>I don't think we have a good selection method yet.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><div class="h5"><div dir="ltr">On Thu, 16 Nov 2017 at 10:09 Grazvydas Ignotas <<a href="mailto:notasas@gmail.com" target="_blank">notasas@gmail.com</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">On Thu, Nov 16, 2017 at 12:33 AM, Dave Airlie <<a href="mailto:airlied@gmail.com" target="_blank">airlied@gmail.com</a>> wrote:<br>
> On 15 November 2017 at 04:40, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>> wrote:<br>
>> This commit significantly reworks the way prime support works and lets<br>
>> us pull it even further into radv.  The old mechanism required the<br>
>> specific WSI layer to be aware of the linear shadow copy that has to be<br>
>> done in order for prime to work.  In the new paradigm, we better define<br>
>> what bits of wsi_image go to the client and what bits go off to the<br>
>> window system.  It's then the job of the driver to allocate two separate<br>
>> images and stash whatever intermediates it needs in driver_private.<br>
>> There are a few advantages to this method:<br>
>><br>
>>  1) It separates supporting prime from the driver decision as to whether<br>
>>     it's better to render directly into the window-system-compatible<br>
>>     image or if it's better to blit.<br>
>><br>
>>  2) Because of this separation, it's now possible for a driver to use a<br>
>>     different scheme for WSI image presentation where it hooks the<br>
>>     vkCmdPipelineBarrier that transitions the image to<br>
>>     VK_IMAGE_LAYOUT_PRESENT_SRC_<wbr>KHR and does the blit there.<br>
>><br>
>>  3) It lets us pull more of the details into radv and, in my opinion,<br>
>>     actually makes the radv code more straightforward.<br>
><br>
> For the record, PRIME is not radv specific, stop trying to make it so,<br>
> anv should support display to other GPUs.<br>
<br>
Yes it would be great if that worked, would make radv vs anv testing<br>
so much easier as I much prefer my display to be on dGPU.<br></div></div></blockquote></div>
</blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Before this conversation goes much further, I think I should say that this patch is getting scrapped entirely.  Dave and I spent a bunch of time yesterday rewriting the universe of Vulkan WSI to move in the direction of more common code.  One of the natural fall-outs of that is that anv gets prime support for free.</div><div class="gmail_extra"><br></div><div class="gmail_extra">--Jason<br></div></div>