[Mesa-dev] [PATCH 2/3] egl: Wrap dri3 surface primitive around dri2 egl surface

[Emil Velikov]

On 15 September 2017 at 17:37, Marathe, Yogesh <yogesh.marathe at intel.com> wrote:
> Hi Emil,
>
>>-----Original Message-----
>>From: Emil Velikov [mailto:emil.l.velikov at gmail.com]
>>Sent: Friday, September 15, 2017 9:52 PM
>>To: Marathe, Yogesh <yogesh.marathe at intel.com>
>>Cc: Eric Engestrom <eric.engestrom at imgtec.com>; mesa-
>>dev at lists.freedesktop.org
>>Subject: Re: [Mesa-dev] [PATCH 2/3] egl: Wrap dri3 surface primitive around dri2
>>egl surface
>>
>>On 15 September 2017 at 16:48, Marathe, Yogesh <yogesh.marathe at intel.com>
>>wrote:
>>> Hi Eric,
>>>
>>>>-----Original Message-----
>>>>From: Eric Engestrom [mailto:eric.engestrom at imgtec.com]
>>>>Sent: Friday, September 15, 2017 7:13 PM
>>>>To: Marathe, Yogesh <yogesh.marathe at intel.com>
>>>>Cc: mesa-dev at lists.freedesktop.org
>>>>Subject: Re: [Mesa-dev] [PATCH 2/3] egl: Wrap dri3 surface primitive
>>>>around dri2 egl surface
>>>>
>>>>On Friday, 2017-09-15 12:06:57 +0530, yogesh.marathe at intel.com wrote:
>>>>> From: Yogesh Marathe <yogesh.marathe at intel.com>
>>>>>
>>>>> Originally dri3 egl surface was wrapped around _EGLSurface. To
>>>>> support explicit sync, new variables (e.g. enable_out_fence) were
>>>>> added to dri2_egl_surface. As we reference these new variables we
>>>>> write on to
>>>>> dri3 loader bits. These get toggled later in execution due to dri3
>>>>> loader. This results in enable_out_fence to have garbage value and
>>>>> further triggers an assert on dri3 platforms even where fences are
>>>>> not supported in kernel.
>>>>>
>>>>> Thanks to Rafael Antognolli, Emil Velikov and Mark Janes for
>>>>> catching and root causing this.
>>>>>
>>>>> Tested with Intel Mesa CI.
>>>>
>>>>I assume you only tested the result of the 3 patches combined, because
>>>>I'm pretty sure mesa can't compile after patches 1/3 and 2/3: 1/3
>>>>makes use of the s/base/surf.base/ change before this patch does that
>>>>change, and with this patch
>>>>(2/3) the changes in 3/3 are needed as well.
>>>>
>>>>Please run
>>>>$ git rebase --interactive --exec make origin/master on your branch to
>>>>make sure each commit compiles.
>>>
>>> Ok. Yes I tested the result combined. My assumption was these three
>>> will always be applied or reverted together. 2/3 and 3/3 can't be
>>> separated anyways, but I split them based on irc discussion.
>>>
>>> I'll run the command you've mentioned so 1/3 will be compliable
>>> individually and 2/3, 3/3 together. I hope that’s fine.
>>>
>>Seems like you've went in the opposite direction to what I mentioned on IRC.
>>There's a few rules which apply to nearly every project:
>> - though shalt not intentionally break code, only to fix it with sequential commit
>> - though shalt not merge logically separate changes into the same patch
>
> My last question on this remained unanswered / was lost in other discussion and I was
> exactly asking this, how to split it in this case. I thought I can not separate
> platform_x11_dri3 from 1/3 but your recent reply on 1/3 clarifies. I need to use
> _eglInitSurface instead of dri2_init_surface.
>
> Anyways, now 1/3 will be individually compliable and executable. 2/3 and 3/3 will be
> together compliable and  executable. All changes pertaining to platform_x11_dri3 will
> be into 2/3 and 3/3. Does this sound ok?
>
Instead of going in circles, again, I've re-spinned the series.
Please give it a look carefully observe the changes.

I hope you're use some of the approach in your future work.

Thanks
Emil