On 15 September 2017 at 17:37, Marathe, Yogesh <yogesh.mara...@intel.com> wrote: > Hi Emil, > >>-----Original Message----- >>From: Emil Velikov [mailto:emil.l.veli...@gmail.com] >>Sent: Friday, September 15, 2017 9:52 PM >>To: Marathe, Yogesh <yogesh.mara...@intel.com> >>Cc: Eric Engestrom <eric.engest...@imgtec.com>; mesa- >>d...@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.mara...@intel.com> >>wrote: >>> Hi Eric, >>> >>>>-----Original Message----- >>>>From: Eric Engestrom [mailto:eric.engest...@imgtec.com] >>>>Sent: Friday, September 15, 2017 7:13 PM >>>>To: Marathe, Yogesh <yogesh.mara...@intel.com> >>>>Cc: mesa-dev@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.mara...@intel.com wrote: >>>>> From: Yogesh Marathe <yogesh.mara...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
