<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 28, 2016 at 2:14 PM, Michel Dänzer <span dir="ltr"><<a href="mailto:michel@daenzer.net" target="_blank">michel@daenzer.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 28/10/16 03:58 PM, Nayan Deshmukh wrote:<br>
> On Fri, Oct 28, 2016 at 7:00 AM, Michel Dänzer <<a href="mailto:michel@daenzer.net">michel@daenzer.net</a><br>
</span><span class="">> <mailto:<a href="mailto:michel@daenzer.net">michel@daenzer.net</a>>> wrote:<br>
><br>
>     On 28/10/16 03:08 AM, Marek Olšák wrote:<br>
</span>>     > On Thu, Oct 27, 2016 at 5:23 PM, Emil Velikov <<a href="mailto:emil.l.velikov@gmail.com">emil.l.velikov@gmail.com</a> <mailto:<a href="mailto:emil.l.velikov@gmail.com">emil.l.velikov@gmail.<wbr>com</a>>> wrote:<br>
<span class="">>     >> On 17 October 2016 at 10:37, Marek Olšák <<a href="mailto:maraeo@gmail.com">maraeo@gmail.com</a> <mailto:<a href="mailto:maraeo@gmail.com">maraeo@gmail.com</a>>> wrote:<br>
>     >>> Reverting the whole commit is too much. You can just remove the PIPE BIND<br>
>     >>> SHARED usage if you need to.<br>
>     >>><br>
>     >> I'd imagine that one wants to check if radeon(s) behave OK with the<br>
>     >> flag dropped ? Thus it might be better for someone with radeon HW to<br>
>     >> give it a bash.<br>
>     >> Can we have a volunteer please :-)<br>
>     ><br>
>     > r600-radeonsi ignore PIPE_BIND_SHARED on textures.<br>
><br>
>     That doesn't mean the state tracker can just drop PIPE_BIND_SHARED.<br>
><br>
>     <a href="https://patchwork.freedesktop.org/patch/110569/" rel="noreferrer" target="_blank">https://patchwork.freedesktop.<wbr>org/patch/110569/</a><br>
>     <<a href="https://patchwork.freedesktop.org/patch/110569/" rel="noreferrer" target="_blank">https://patchwork.<wbr>freedesktop.org/patch/110569/</a>> seems the best<br>
>     candidate<br>
>     for resolving the nouveau issue, but I suspect as is it might break DRI3<br>
>     PRIME. Nayan, can you check this and fix it up as necessary? Basically,<br>
>     PIPE_BIND_LINEAR is only really necessary for buffers which are sent to<br>
>     the X server for presentation on a different GPU.<br>
><br>
> It works fine with DRI3 Prime with my I+A system, but I think it won't<br>
> work with a I+N system as it uses PIPE_BIND_SHARE and PIPE_BIND_LINEAR<br>
> together for one buffer.<br>
<br>
</span>The patch above removes PIPE_BIND_LINEAR. Which case are you thinking of?<br><span class=""></span></blockquote><div> </div><div>We also use PIPE_BIND_LINEAR and PIPE_BIND_SHARED when allocating a</div><div>buffer in vl_winsys_dri3.c, so do we also need to change that? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""> <br>
<br>
> Since this buffer is being sent to X we need to have a PIPE_BIND_LINEAR,<br>
> so should I send a patch removing SHARED flag, it is working fine on<br>
> my system without the shared flag.<br>
<br>
</span>PIPE_BIND_LINEAR is only required for buffers which are shared between<br>
different GPUs. Note that in that case it's required with nouveau as well.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
--<br>
Earthling Michel Dänzer               |               <a href="http://www.amd.com" rel="noreferrer" target="_blank">http://www.amd.com</a><br>
Libre software enthusiast             |             Mesa and X developer<br>
</div></div></blockquote></div><br></div></div>