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

[Marathe, Yogesh]

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?

>
>There's expeptions of course, but on an extremely rare situations.
>I'll follow up exactly on each each/how it could be split.
>
>-Emil