[Mesa-dev] [AppVeyor] mesa master #62 failed
Build mesa 62 failed Commit 200859f45c by Caio Marcelo de Oliveira Filho on 8/28/2019 4:14 AM: iris: Enable ARB_gl_spirv and ARB_spirv_extensions Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Concern about proposed patch "egl/android: remove HAL_PIXEL_FORMAT_BGRA_8888 support"
On Tue, Aug 27, 2019 at 7:14 PM Lepton Wu wrote: > > On Thu, Aug 15, 2019 at 3:31 PM Mauro Rossi wrote: > > > > Hi Lepton, > > > > On Thu, Aug 15, 2019 at 9:58 PM Lepton Wu wrote: > >> > >> That's interesting. The android frame work will hard coded to use > >> RGBA_ and set it as window format here: > >> > >> https://android.googlesource.com/platform/frameworks/native/+/refs/heads/master/opengl/libs/EGL/eglApi.cpp#738 > >> > >> Do you have a custom version of android which do different code here? > > > > > > Affirmative, you may check [1] for reference > > > > [1] > > http://git.osdn.net/view?p=android-x86/frameworks-native.git;a=commit;h=792c8dc009bd3a0c44eb39e757a95e099c03b54c > > > >> > >> > >> For other GPU, like intel, if we choose a EGL config with BGRA , > >> finally we got a wrong color on screen. > > > > > > android-x86 implementation selects BGRA_ only when RGBA_ not > > available, > > in a similar way to a pre-existing Workaround 10194508 that was removed > > from AOSP code > > > > Removing HAL_PIXEL_FORMAT_BGRA_ support from egl/android > > SurfaceFlinger will just crash with SIGABRT on nouveau > Then how about this: since aosp android really doesn't support > HAL_PIXEL_FORMAT_BGRA_, let me guard HAL_PIXEL_FORMAT_BGRA_ > with > a macro, maybe something like #ifdef ENABLE_ANDROID_EGL_CONFIG_BGRA, > and also send a patch at android-x86 side to set it when compiling > mesa. > This make sure it works for aosp android tree and also android-x86 Another idea could be only dropping BGRA config if there is RGBA config, would this work for android-x86? Basically I will check format_count[0], if it's non zero, skip all BGRA configs. > > > >> > >> > >> On Thu, Aug 15, 2019 at 12:49 PM Mauro Rossi wrote: > >> > > >> > Hi, > >> > > >> > sorry if I'm communicating in dedicated thread, but I don't know how to > >> > reply to existing one. > >> > > >> > The proposed patch is based on the wrong assumption that all drivers > >> > used with Android have RGBA_, which is not correct, for example > >> > nouveau does not support RGBA on primary planes, infact we have a > >> > fallback to simpler EGL query in android-x86 and we use BGRA_ (pixel > >> > format = 5) > >> > > >> > If patch does not solve a specific problem and it will cause a > >> > regression at least in nouveau, it is recommended to abandon the patch > >> > > >> > Thanks for your feedbacks > >> > > >> > Mauro ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Concern about proposed patch "egl/android: remove HAL_PIXEL_FORMAT_BGRA_8888 support"
On Thu, Aug 15, 2019 at 3:31 PM Mauro Rossi wrote: > > Hi Lepton, > > On Thu, Aug 15, 2019 at 9:58 PM Lepton Wu wrote: >> >> That's interesting. The android frame work will hard coded to use >> RGBA_ and set it as window format here: >> >> https://android.googlesource.com/platform/frameworks/native/+/refs/heads/master/opengl/libs/EGL/eglApi.cpp#738 >> >> Do you have a custom version of android which do different code here? > > > Affirmative, you may check [1] for reference > > [1] > http://git.osdn.net/view?p=android-x86/frameworks-native.git;a=commit;h=792c8dc009bd3a0c44eb39e757a95e099c03b54c > >> >> >> For other GPU, like intel, if we choose a EGL config with BGRA , >> finally we got a wrong color on screen. > > > android-x86 implementation selects BGRA_ only when RGBA_ not > available, > in a similar way to a pre-existing Workaround 10194508 that was removed from > AOSP code > > Removing HAL_PIXEL_FORMAT_BGRA_ support from egl/android > SurfaceFlinger will just crash with SIGABRT on nouveau Then how about this: since aosp android really doesn't support HAL_PIXEL_FORMAT_BGRA_, let me guard HAL_PIXEL_FORMAT_BGRA_ with a macro, maybe something like #ifdef ENABLE_ANDROID_EGL_CONFIG_BGRA, and also send a patch at android-x86 side to set it when compiling mesa. This make sure it works for aosp android tree and also android-x86 > >> >> >> On Thu, Aug 15, 2019 at 12:49 PM Mauro Rossi wrote: >> > >> > Hi, >> > >> > sorry if I'm communicating in dedicated thread, but I don't know how to >> > reply to existing one. >> > >> > The proposed patch is based on the wrong assumption that all drivers used >> > with Android have RGBA_, which is not correct, for example nouveau >> > does not support RGBA on primary planes, infact we have a fallback to >> > simpler EGL query in android-x86 and we use BGRA_ (pixel format = 5) >> > >> > If patch does not solve a specific problem and it will cause a regression >> > at least in nouveau, it is recommended to abandon the patch >> > >> > Thanks for your feedbacks >> > >> > Mauro ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] broadcom/vc4: Expand width of dst surface
Thank you for your reminding, I've sent [patch v2] to this mailing list, I'd prefer to waiting for response here before I get familiar with gitlab MR. On 2019/8/27 下午6:15, apinheiro wrote: > > On 27/8/19 11:13, Zhaowei Yuan wrote: >> Four bytes of src_surf will be compressed into a 32-bits data >> and stored into dst_surf, and dst_surf is read as z-order,so >> its width must be aligned to multiples of 8(4x2) before devided >> by 2. >> >> Signed-off-by: Zhaowei Yuan >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111266 >> --- >> src/gallium/drivers/vc4/vc4_blit.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/src/gallium/drivers/vc4/vc4_blit.c >> b/src/gallium/drivers/vc4/vc4_blit.c >> index d3cc515..7697bfa 100644 >> --- a/src/gallium/drivers/vc4/vc4_blit.c >> +++ b/src/gallium/drivers/vc4/vc4_blit.c >> @@ -361,6 +361,7 @@ vc4_yuv_blit(struct pipe_context *pctx, const >> struct pipe_blit_info *info) >> return false; >> } >> dst_surf->width /= 2; >> + dst_surf->width = align(dst_surf->width, 8) / 2; > > > The commit message and what you are doing here is somewhat > inconsistent, as you are dividing by two twice. Shouldn't the previous > width division being replaced instead of adding a new aligned one? It > is somewhat confusing to divide by two, and then align and divide by > two again. > > FWIW, at this point it would be advisable if you send vc4/v3d patches > as gitlab MR, as lately we are using it more that the mesa list. > > > BR > >> if (dst->cpp == 1) >> dst_surf->height /= 2; > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] broadcom/vc4: Expand width of dst surface
Four bytes of src_surf will be compressed into a 32-bits data and stored into dst_surf, and dst_surf is read as z-order,so its width must be aligned to multiples of 8(4x2) before devided by 2. Signed-off-by: Zhaowei Yuan Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111266 --- src/gallium/drivers/vc4/vc4_blit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/vc4/vc4_blit.c b/src/gallium/drivers/vc4/vc4_blit.c index d3cc515..d379bcc 100644 --- a/src/gallium/drivers/vc4/vc4_blit.c +++ b/src/gallium/drivers/vc4/vc4_blit.c @@ -360,7 +360,7 @@ vc4_yuv_blit(struct pipe_context *pctx, const struct pipe_blit_info *info) util_blitter_unset_running_flag(vc4->blitter); return false; } -dst_surf->width /= 2; +dst_surf->width = align(dst_surf->width, 8) / 2; if (dst->cpp == 1) dst_surf->height /= 2; -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: fix texStore for FORMAT_Z32_FLOAT_S8X24_UINT
By the way, I took the liberty of composing a test which fails with
current mesa, and I'm pretty sure it continues to fail with this
patch. It does pass if I just make it a GLubyte like all the other
instances of the code already do.
Piglit test: https://patchwork.freedesktop.org/patch/327460/
On Tue, Aug 27, 2019 at 7:37 PM Ilia Mirkin wrote:
>
> I don't think the original author was included -- CC was probably
> stripped by the ML. Adding here.
>
> On Tue, Aug 27, 2019 at 6:49 PM Marek Olšák wrote:
> >
> > Yes, but if the original author doesn't reply, I'd like to push this.
> >
> > Marek
> >
> > On Thu, Aug 15, 2019 at 8:01 PM Ilia Mirkin wrote:
> >>
> >> Subtle. The source format *can* be 64-bit, by the way, but if it's
> >> GL_DEPTH_COMPONENT it may well be 32-bit.
> >>
> >> But what if it's GL_STENCIL_INDEX -- could it not be 1-byte? IOW,
> >> should this just be a char *, and use byte addressing and be done with
> >> it?
> >>
> >> On Thu, Aug 15, 2019 at 7:56 PM Marek Olšák wrote:
> >> >
> >> > From: Jiadong Zhu
> >> >
> >> > _mesa_texstore_z32f_x24s8 calculates source rowStride at a
> >> > pace of 64-bit, this will make inaccuracy offset if the width
> >> > of src image is an odd number. Modify src pointer to int_32* as
> >> > source image format is gl_float which is 32-bit per pixel.
> >> >
> >> > Signed-off-by: Jiadong Zhu
> >> > Signed-off-by: Marek Olšák
> >> > ---
> >> > src/mesa/main/texstore.c | 6 +++---
> >> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >> > mode change 100644 => 100755 src/mesa/main/texstore.c
> >> >
> >> > diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
> >> > old mode 100644
> >> > new mode 100755
> >> > index 2913d4bc067..207695041a7
> >> > --- a/src/mesa/main/texstore.c
> >> > +++ b/src/mesa/main/texstore.c
> >> > @@ -531,35 +531,35 @@ _mesa_texstore_s8(TEXSTORE_PARAMS)
> >> > return GL_TRUE;
> >> > }
> >> >
> >> >
> >> > static GLboolean
> >> > _mesa_texstore_z32f_x24s8(TEXSTORE_PARAMS)
> >> > {
> >> > GLint img, row;
> >> > const GLint srcRowStride
> >> >= _mesa_image_row_stride(srcPacking, srcWidth, srcFormat, srcType)
> >> > - / sizeof(uint64_t);
> >> > + / sizeof(int32_t);
> >> >
> >> > assert(dstFormat == MESA_FORMAT_Z32_FLOAT_S8X24_UINT);
> >> > assert(srcFormat == GL_DEPTH_STENCIL ||
> >> >srcFormat == GL_DEPTH_COMPONENT ||
> >> >srcFormat == GL_STENCIL_INDEX);
> >> > assert(srcFormat != GL_DEPTH_STENCIL ||
> >> >srcType == GL_UNSIGNED_INT_24_8 ||
> >> >srcType == GL_FLOAT_32_UNSIGNED_INT_24_8_REV);
> >> >
> >> > /* In case we only upload depth we need to preserve the stencil */
> >> > for (img = 0; img < srcDepth; img++) {
> >> >uint64_t *dstRow = (uint64_t *) dstSlices[img];
> >> > - const uint64_t *src
> >> > - = (const uint64_t *) _mesa_image_address(dims, srcPacking,
> >> > srcAddr,
> >> > + const int32_t *src
> >> > + = (const int32_t *) _mesa_image_address(dims, srcPacking,
> >> > srcAddr,
> >> > srcWidth, srcHeight,
> >> > srcFormat, srcType,
> >> > img, 0, 0);
> >> >for (row = 0; row < srcHeight; row++) {
> >> > /* The unpack functions with:
> >> >*dstType = GL_FLOAT_32_UNSIGNED_INT_24_8_REV
> >> >* only write their own dword, so the other dword (stencil
> >> >* or depth) is preserved. */
> >> > if (srcFormat != GL_STENCIL_INDEX)
> >> > _mesa_unpack_depth_span(ctx, srcWidth,
> >> > --
> >> > 2.17.1
> >> >
> >> > ___
> >> > mesa-dev mailing list
> >> > mesa-dev@lists.freedesktop.org
> >> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa GitLab <-> AppVeyor integration
On Tuesday, 2019-08-27 13:31:22 +, Jose Fonseca wrote: > Appveyor seems to be building other MR 1781: > > https://ci.appveyor.com/project/mesa3d/mesa-re1yd/builds/26989425 > https://ci.appveyor.com/project/mesa3d/mesa-re1yd/history > https://gitlab.freedesktop.org/eric/mesa/pipelines/59190 You shouldn't take my MRs as an example for this, as I've set up the hook on my account, so my MRs always get picked up by appveyor :) > > I don't know what's special about MR 1779. Perhaps it's just the sheer > volume of merges and merge requests? > > Jose > > > From: Eric Engestrom > Sent: Tuesday, August 27, 2019 14:23 > To: Jose Fonseca > Cc: mesa-dev@lists.freedesktop.org ; Brian > Paul > Subject: Re: Mesa GitLab <-> AppVeyor integration > > On Tuesday, 2019-08-27 10:30:07 +, Jose Fonseca wrote: > > FYI, I've followed Eric Engestroms' instructions for better Mesa <-> > > AppVeyor integration. (Thanks Eric.) > > > > I haven't tested, but hopefully this new integration method should now > > trigger Appveyor builds on pull requests too, which should come handy. > > > > I'm still keeping the old webhook method integration around (with a > > different name.) So the list might receive duplicate notifications. I'll > > disable this when we're satisfied the new method works well. > > > > For the record, these Appveyor runs are running on a separate Appveyor > > account dedicated for Mesa and FDO projects like Piglit, and not my > > personal Appveyor account. > > > > Jose > > Thanks! > > Looks like it didn't quite work though... MR !1779 [1] was created after > your email, and doesn't have the [external/appveyor] job on its pipeline. > > I doubt there's much I could do that you can't to try to debug this, but > feel free to ask me :) > > [1] > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2Fmerge_requests%2F1779data=02%7C01%7Cjfonseca%40vmware.com%7C9bd7988d457342fb2a2808d72af1d2a2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637025090427847960sdata=3G9tePq%2BMLG1Yw%2FWr92MCo1ksWwe7exFKqoxhS2LmQU%3Dreserved=0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: fix texStore for FORMAT_Z32_FLOAT_S8X24_UINT
I don't think the original author was included -- CC was probably
stripped by the ML. Adding here.
On Tue, Aug 27, 2019 at 6:49 PM Marek Olšák wrote:
>
> Yes, but if the original author doesn't reply, I'd like to push this.
>
> Marek
>
> On Thu, Aug 15, 2019 at 8:01 PM Ilia Mirkin wrote:
>>
>> Subtle. The source format *can* be 64-bit, by the way, but if it's
>> GL_DEPTH_COMPONENT it may well be 32-bit.
>>
>> But what if it's GL_STENCIL_INDEX -- could it not be 1-byte? IOW,
>> should this just be a char *, and use byte addressing and be done with
>> it?
>>
>> On Thu, Aug 15, 2019 at 7:56 PM Marek Olšák wrote:
>> >
>> > From: Jiadong Zhu
>> >
>> > _mesa_texstore_z32f_x24s8 calculates source rowStride at a
>> > pace of 64-bit, this will make inaccuracy offset if the width
>> > of src image is an odd number. Modify src pointer to int_32* as
>> > source image format is gl_float which is 32-bit per pixel.
>> >
>> > Signed-off-by: Jiadong Zhu
>> > Signed-off-by: Marek Olšák
>> > ---
>> > src/mesa/main/texstore.c | 6 +++---
>> > 1 file changed, 3 insertions(+), 3 deletions(-)
>> > mode change 100644 => 100755 src/mesa/main/texstore.c
>> >
>> > diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
>> > old mode 100644
>> > new mode 100755
>> > index 2913d4bc067..207695041a7
>> > --- a/src/mesa/main/texstore.c
>> > +++ b/src/mesa/main/texstore.c
>> > @@ -531,35 +531,35 @@ _mesa_texstore_s8(TEXSTORE_PARAMS)
>> > return GL_TRUE;
>> > }
>> >
>> >
>> > static GLboolean
>> > _mesa_texstore_z32f_x24s8(TEXSTORE_PARAMS)
>> > {
>> > GLint img, row;
>> > const GLint srcRowStride
>> >= _mesa_image_row_stride(srcPacking, srcWidth, srcFormat, srcType)
>> > - / sizeof(uint64_t);
>> > + / sizeof(int32_t);
>> >
>> > assert(dstFormat == MESA_FORMAT_Z32_FLOAT_S8X24_UINT);
>> > assert(srcFormat == GL_DEPTH_STENCIL ||
>> >srcFormat == GL_DEPTH_COMPONENT ||
>> >srcFormat == GL_STENCIL_INDEX);
>> > assert(srcFormat != GL_DEPTH_STENCIL ||
>> >srcType == GL_UNSIGNED_INT_24_8 ||
>> >srcType == GL_FLOAT_32_UNSIGNED_INT_24_8_REV);
>> >
>> > /* In case we only upload depth we need to preserve the stencil */
>> > for (img = 0; img < srcDepth; img++) {
>> >uint64_t *dstRow = (uint64_t *) dstSlices[img];
>> > - const uint64_t *src
>> > - = (const uint64_t *) _mesa_image_address(dims, srcPacking,
>> > srcAddr,
>> > + const int32_t *src
>> > + = (const int32_t *) _mesa_image_address(dims, srcPacking,
>> > srcAddr,
>> > srcWidth, srcHeight,
>> > srcFormat, srcType,
>> > img, 0, 0);
>> >for (row = 0; row < srcHeight; row++) {
>> > /* The unpack functions with:
>> >*dstType = GL_FLOAT_32_UNSIGNED_INT_24_8_REV
>> >* only write their own dword, so the other dword (stencil
>> >* or depth) is preserved. */
>> > if (srcFormat != GL_STENCIL_INDEX)
>> > _mesa_unpack_depth_span(ctx, srcWidth,
>> > --
>> > 2.17.1
>> >
>> > ___
>> > mesa-dev mailing list
>> > mesa-dev@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: fix texStore for FORMAT_Z32_FLOAT_S8X24_UINT
Yes, but if the original author doesn't reply, I'd like to push this.
Marek
On Thu, Aug 15, 2019 at 8:01 PM Ilia Mirkin wrote:
> Subtle. The source format *can* be 64-bit, by the way, but if it's
> GL_DEPTH_COMPONENT it may well be 32-bit.
>
> But what if it's GL_STENCIL_INDEX -- could it not be 1-byte? IOW,
> should this just be a char *, and use byte addressing and be done with
> it?
>
> On Thu, Aug 15, 2019 at 7:56 PM Marek Olšák wrote:
> >
> > From: Jiadong Zhu
> >
> > _mesa_texstore_z32f_x24s8 calculates source rowStride at a
> > pace of 64-bit, this will make inaccuracy offset if the width
> > of src image is an odd number. Modify src pointer to int_32* as
> > source image format is gl_float which is 32-bit per pixel.
> >
> > Signed-off-by: Jiadong Zhu
> > Signed-off-by: Marek Olšák
> > ---
> > src/mesa/main/texstore.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> > mode change 100644 => 100755 src/mesa/main/texstore.c
> >
> > diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
> > old mode 100644
> > new mode 100755
> > index 2913d4bc067..207695041a7
> > --- a/src/mesa/main/texstore.c
> > +++ b/src/mesa/main/texstore.c
> > @@ -531,35 +531,35 @@ _mesa_texstore_s8(TEXSTORE_PARAMS)
> > return GL_TRUE;
> > }
> >
> >
> > static GLboolean
> > _mesa_texstore_z32f_x24s8(TEXSTORE_PARAMS)
> > {
> > GLint img, row;
> > const GLint srcRowStride
> >= _mesa_image_row_stride(srcPacking, srcWidth, srcFormat, srcType)
> > - / sizeof(uint64_t);
> > + / sizeof(int32_t);
> >
> > assert(dstFormat == MESA_FORMAT_Z32_FLOAT_S8X24_UINT);
> > assert(srcFormat == GL_DEPTH_STENCIL ||
> >srcFormat == GL_DEPTH_COMPONENT ||
> >srcFormat == GL_STENCIL_INDEX);
> > assert(srcFormat != GL_DEPTH_STENCIL ||
> >srcType == GL_UNSIGNED_INT_24_8 ||
> >srcType == GL_FLOAT_32_UNSIGNED_INT_24_8_REV);
> >
> > /* In case we only upload depth we need to preserve the stencil */
> > for (img = 0; img < srcDepth; img++) {
> >uint64_t *dstRow = (uint64_t *) dstSlices[img];
> > - const uint64_t *src
> > - = (const uint64_t *) _mesa_image_address(dims, srcPacking,
> srcAddr,
> > + const int32_t *src
> > + = (const int32_t *) _mesa_image_address(dims, srcPacking,
> srcAddr,
> > srcWidth, srcHeight,
> > srcFormat, srcType,
> > img, 0, 0);
> >for (row = 0; row < srcHeight; row++) {
> > /* The unpack functions with:
> >*dstType = GL_FLOAT_32_UNSIGNED_INT_24_8_REV
> >* only write their own dword, so the other dword (stencil
> >* or depth) is preserved. */
> > if (srcFormat != GL_STENCIL_INDEX)
> > _mesa_unpack_depth_span(ctx, srcWidth,
> > --
> > 2.17.1
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #35 completed
Build mesa 35 completed Commit d8f27552f4 by Daniel Kolesa on 8/27/2019 8:29 PM: util: add auxv based PowerPC AltiVec/VSX detection Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #34 failed
Build mesa 34 failed Commit d8f27552f4 by Daniel Kolesa on 8/27/2019 8:17 PM: src/util/u_cpu_detect.c: add PowerPC auxv AltiVec/VSX detection Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #31 completed
Build mesa 31 completed Commit 6342d43ae9 by Kenneth Graunke on 8/27/2019 8:14 PM: iris: Delete dead prototype Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #30 failed
Build mesa 30 failed Commit 2734a4951e by Daniel Kolesa on 8/27/2019 8:14 PM: src/util/u_cpu_detect.c: add PowerPC auxv AltiVec/VSX detection Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #28 completed
Build mesa 28 completed Commit 2734a4951e by q66 on 8/27/2019 8:01 PM: src/util/u_cpu_detect.c: add PowerPC auxv AltiVec/VSX detection Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #27 failed
Build mesa 27 failed Commit 2734a4951e by q66 on 8/27/2019 7:58 PM: src/util/u_cpu_detect.c: add PowerPC auxv AltiVec/VSX detection Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Navi14 for 19.2
+ Juan, Emil, Jeremy Thanks, Marek On Mon, Aug 26, 2019 at 3:05 PM Marek Olšák wrote: > Hi, > > I'd like to push the Navi14 merge request to 19.2 no later than Tuesday > August 27. > > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1726 > > Please ack if it's OK with you, > > Thanks, > Marek > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111504] how to know the use of the Lima driver
https://bugs.freedesktop.org/show_bug.cgi?id=111504 Bug ID: 111504 Summary: how to know the use of the Lima driver Product: Mesa Version: 19.1 Hardware: ARM OS: Linux (All) Status: NEW Severity: not set Priority: not set Component: Drivers/Gallium/Lima Assignee: mesa-dev@lists.freedesktop.org Reporter: m.ort...@telefonica.net I have compiled and installed Mesa 19.1.5 with the instructions specified in https://gitlab.freedesktop.org/lima/web/wikis/home. My system is Odroid U3 (Exynos 4412) with kernel 5.3-rc3 and Ubuntu 18.04. How can I know that the es2gears or es2_info demos are using the Lima driver? -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] scons: Make GCC builds stricter.
Am 27.08.19 um 12:57 schrieb Jose Fonseca: > Uses some of the same -Werror options used by Meson, as suggested by > Michel Daezer. > --- > scons/gallium.py | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/scons/gallium.py b/scons/gallium.py > index 21197c8d0d1..2eff4174257 100755 > --- a/scons/gallium.py > +++ b/scons/gallium.py > @@ -473,7 +473,10 @@ def generate(env): > '-fmessage-length=0', # be nice to Eclipse > ] > cflags += [ > -'-Wmissing-prototypes', > +'-Werror=implicit-function-declaration', > +'-Werror=missing-prototypes', > +'-Werror=return-type', > +'-Werror=incompatible-pointer-types', > '-std=gnu99', > ] > if icc: > For the series: Reviewed-by: Roland Scheidegger ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] glx: Fix incompatible function pointer types.
On Tue, 2019-08-27 at 10:57 +, Jose Fonseca wrote: > I don't know how Meson didn't hit this issue, when it too already uses > -Werror=incompatible-pointer-types Yeah, weird. Reviewed-by: Adam Jackson - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] panfrost: Don't use mir_foreach_instr_in_block_safe() when not needed
On Tue, 27 Aug 2019 07:25:03 -0700 Alyssa Rosenzweig wrote: > Assuming it passes CI, feel free to apply it :) I guess that stands for a R-b :-). > > On Tue, Aug 27, 2019 at 12:40:08PM +0200, Boris Brezillon wrote: > > On Tue, 13 Aug 2019 15:30:20 -0700 > > Alyssa Rosenzweig wrote: > > > > > > I don't see any remove_ins()/insert_before() call in there. Do you see > > > > any reason for using the _safe() variant here? > > > > > > Er, I think I meant the outer loop, which has a remove/insert pair at > > > the bottom to change the current instruction. > > > > Should I apply this patch or do you prefer to keep using the _safe() > > variant even if it's not needed? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/5] panfrost: Free the instruction object in mir_remove_instruction()
On Tue, 27 Aug 2019 07:24:36 -0700
Alyssa Rosenzweig wrote:
> Patches 1, 2, and 5 are:
>
> Reviewed-by: Alyssa Rosenzweig
>
> Patches 3 and 4 are modifying the guts of the scheduler which I plan to
> rewrite in full, like, today.
No problem. I guess you can fix those problem as part of this
full-rewrite then ;-).
>
> On Tue, Aug 27, 2019 at 12:36:40PM +0200, Boris Brezillon wrote:
> > To avoid memory leaks.
> >
> > Signed-off-by: Boris Brezillon
> > ---
> > src/panfrost/midgard/compiler.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/src/panfrost/midgard/compiler.h
> > b/src/panfrost/midgard/compiler.h
> > index 099d108142b1..f9ba31b5959d 100644
> > --- a/src/panfrost/midgard/compiler.h
> > +++ b/src/panfrost/midgard/compiler.h
> > @@ -315,6 +315,7 @@ static inline void
> > mir_remove_instruction(struct midgard_instruction *ins)
> > {
> > list_del(>link);
> > +free(ins);
> > }
> >
> > static inline midgard_instruction*
> > --
> > 2.21.0
> >
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] panfrost: Don't use mir_foreach_instr_in_block_safe() when not needed
Assuming it passes CI, feel free to apply it :) On Tue, Aug 27, 2019 at 12:40:08PM +0200, Boris Brezillon wrote: > On Tue, 13 Aug 2019 15:30:20 -0700 > Alyssa Rosenzweig wrote: > > > > I don't see any remove_ins()/insert_before() call in there. Do you see > > > any reason for using the _safe() variant here? > > > > Er, I think I meant the outer loop, which has a remove/insert pair at > > the bottom to change the current instruction. > > Should I apply this patch or do you prefer to keep using the _safe() > variant even if it's not needed? signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/5] panfrost: Free the instruction object in mir_remove_instruction()
Patches 1, 2, and 5 are:
Reviewed-by: Alyssa Rosenzweig
Patches 3 and 4 are modifying the guts of the scheduler which I plan to
rewrite in full, like, today.
On Tue, Aug 27, 2019 at 12:36:40PM +0200, Boris Brezillon wrote:
> To avoid memory leaks.
>
> Signed-off-by: Boris Brezillon
> ---
> src/panfrost/midgard/compiler.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/panfrost/midgard/compiler.h b/src/panfrost/midgard/compiler.h
> index 099d108142b1..f9ba31b5959d 100644
> --- a/src/panfrost/midgard/compiler.h
> +++ b/src/panfrost/midgard/compiler.h
> @@ -315,6 +315,7 @@ static inline void
> mir_remove_instruction(struct midgard_instruction *ins)
> {
> list_del(>link);
> +free(ins);
> }
>
> static inline midgard_instruction*
> --
> 2.21.0
>
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa GitLab <-> AppVeyor integration
Appveyor seems to be building other MR 1781: https://ci.appveyor.com/project/mesa3d/mesa-re1yd/builds/26989425 https://ci.appveyor.com/project/mesa3d/mesa-re1yd/history https://gitlab.freedesktop.org/eric/mesa/pipelines/59190 I don't know what's special about MR 1779. Perhaps it's just the sheer volume of merges and merge requests? Jose From: Eric Engestrom Sent: Tuesday, August 27, 2019 14:23 To: Jose Fonseca Cc: mesa-dev@lists.freedesktop.org ; Brian Paul Subject: Re: Mesa GitLab <-> AppVeyor integration On Tuesday, 2019-08-27 10:30:07 +, Jose Fonseca wrote: > FYI, I've followed Eric Engestroms' instructions for better Mesa <-> AppVeyor > integration. (Thanks Eric.) > > I haven't tested, but hopefully this new integration method should now > trigger Appveyor builds on pull requests too, which should come handy. > > I'm still keeping the old webhook method integration around (with a different > name.) So the list might receive duplicate notifications. I'll disable this > when we're satisfied the new method works well. > > For the record, these Appveyor runs are running on a separate Appveyor > account dedicated for Mesa and FDO projects like Piglit, and not my personal > Appveyor account. > > Jose Thanks! Looks like it didn't quite work though... MR !1779 [1] was created after your email, and doesn't have the [external/appveyor] job on its pipeline. I doubt there's much I could do that you can't to try to debug this, but feel free to ask me :) [1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2Fmerge_requests%2F1779data=02%7C01%7Cjfonseca%40vmware.com%7C9bd7988d457342fb2a2808d72af1d2a2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637025090427847960sdata=3G9tePq%2BMLG1Yw%2FWr92MCo1ksWwe7exFKqoxhS2LmQU%3Dreserved=0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa GitLab <-> AppVeyor integration
On Tuesday, 2019-08-27 10:30:07 +, Jose Fonseca wrote: > FYI, I've followed Eric Engestroms' instructions for better Mesa <-> AppVeyor > integration. (Thanks Eric.) > > I haven't tested, but hopefully this new integration method should now > trigger Appveyor builds on pull requests too, which should come handy. > > I'm still keeping the old webhook method integration around (with a different > name.) So the list might receive duplicate notifications. I'll disable this > when we're satisfied the new method works well. > > For the record, these Appveyor runs are running on a separate Appveyor > account dedicated for Mesa and FDO projects like Piglit, and not my personal > Appveyor account. > > Jose Thanks! Looks like it didn't quite work though... MR !1779 [1] was created after your email, and doesn't have the [external/appveyor] job on its pipeline. I doubt there's much I could do that you can't to try to debug this, but feel free to ask me :) [1] https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1779 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] util: Prevent implicit declaration of function getenv.
On Tuesday, 2019-08-27 10:57:38 +, Jose Fonseca wrote: > With MinGW cross compilation. 2-4 are Acked-by: Eric Engestrom > --- > src/util/os_misc.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/util/os_misc.c b/src/util/os_misc.c > index 755970430b0..436bc38604b 100644 > --- a/src/util/os_misc.c > +++ b/src/util/os_misc.c > @@ -38,6 +38,7 @@ > #endif > #include > #include > +#include > > #else > > -- > 2.17.1 > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] scons: Make GCC builds stricter.
For the series, Reviewed-by: Brian Paul On 08/27/2019 04:57 AM, Jose Fonseca wrote: Uses some of the same -Werror options used by Meson, as suggested by Michel Daezer. --- scons/gallium.py | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/scons/gallium.py b/scons/gallium.py index 21197c8d0d1..2eff4174257 100755 --- a/scons/gallium.py +++ b/scons/gallium.py @@ -473,7 +473,10 @@ def generate(env): '-fmessage-length=0', # be nice to Eclipse ] cflags += [ -'-Wmissing-prototypes', +'-Werror=implicit-function-declaration', +'-Werror=missing-prototypes', +'-Werror=return-type', +'-Werror=incompatible-pointer-types', '-std=gnu99', ] if icc: ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] glx: Fix incompatible function pointer types.
On Tuesday, 2019-08-27 10:57:36 +, Jose Fonseca wrote:
> I don't know how Meson didn't hit this issue, when it too already uses
> -Werror=incompatible-pointer-types
Not sure either...
Fixes: 3dd299c3d5b88114894e ("glx: Sync with Khronos")
Reviewed-by: Eric Engestrom
> ---
> src/mesa/drivers/x11/glxapi.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/x11/glxapi.h b/src/mesa/drivers/x11/glxapi.h
> index 90323a24731..6a1ce66a891 100644
> --- a/src/mesa/drivers/x11/glxapi.h
> +++ b/src/mesa/drivers/x11/glxapi.h
> @@ -143,7 +143,7 @@ struct _glxapi_table {
> /*** GLX_SGIX_pbuffer ***/
> GLXPbufferSGIX (*CreateGLXPbufferSGIX)(Display *, GLXFBConfigSGIX,
> unsigned int, unsigned int, int *);
> void (*DestroyGLXPbufferSGIX)(Display *, GLXPbufferSGIX);
> - int (*QueryGLXPbufferSGIX)(Display *, GLXPbufferSGIX, int, unsigned int
> *);
> + void (*QueryGLXPbufferSGIX)(Display *, GLXPbufferSGIX, int, unsigned int
> *);
> void (*SelectEventSGIX)(Display *, GLXDrawable, unsigned long);
> void (*GetSelectedEventSGIX)(Display *, GLXDrawable, unsigned long *);
>
> --
> 2.17.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/5] panfrost: Fix a list_assert() in schedule_block()
On Tue, 27 Aug 2019 12:36:42 +0200
Boris Brezillon wrote:
> list_for_each_entry() does not allow modifying the current item pointer.
> Let's rework the skip-instructions logic in schedule_block() to not
> break this rule.
>
> Signed-off-by: Boris Brezillon
> ---
> src/panfrost/midgard/midgard_schedule.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/panfrost/midgard/midgard_schedule.c
> b/src/panfrost/midgard/midgard_schedule.c
> index f80a0354fb88..57b0904cf007 100644
> --- a/src/panfrost/midgard/midgard_schedule.c
> +++ b/src/panfrost/midgard/midgard_schedule.c
> @@ -581,8 +581,11 @@ schedule_block(compiler_context *ctx, midgard_block
> *block)
>
> block->quadword_count = 0;
>
> +int skip = 0;
> mir_foreach_instr_in_block(block, ins) {
> -int skip;
> +if (skip--)
> +continue;
> +
Hm, should be
if (skip) {
skip--;
continue;
}
I'll fix that in v2.
> midgard_bundle bundle = schedule_bundle(ctx, block, ins,
> );
> util_dynarray_append(>bundles, midgard_bundle,
> bundle);
>
> @@ -592,9 +595,6 @@ schedule_block(compiler_context *ctx, midgard_block
> *block)
> ctx->blend_constant_offset = quadwords_within_block
> * 0x10;
> }
>
> -while(skip--)
> -ins = mir_next_op(ins);
> -
> block->quadword_count += quadword_size(bundle.tag);
> }
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa staging/19.1 #1 completed
Build mesa 1 completed Commit e4df7ffc23 by Paulo Zanoni on 8/14/2019 12:02 AM: intel/fs: grab fail_msg from v32 instead of v16 when v32->run_cs fails Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] scons: Make GCC builds stricter.
Uses some of the same -Werror options used by Meson, as suggested by Michel Daezer. --- scons/gallium.py | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/scons/gallium.py b/scons/gallium.py index 21197c8d0d1..2eff4174257 100755 --- a/scons/gallium.py +++ b/scons/gallium.py @@ -473,7 +473,10 @@ def generate(env): '-fmessage-length=0', # be nice to Eclipse ] cflags += [ -'-Wmissing-prototypes', +'-Werror=implicit-function-declaration', +'-Werror=missing-prototypes', +'-Werror=return-type', +'-Werror=incompatible-pointer-types', '-std=gnu99', ] if icc: -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] util: Prevent strcasecmp macro redefinion.
MinGW headers already define it. --- src/util/u_string.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/util/u_string.h b/src/util/u_string.h index 5fea8f17e73..361dcb41e2b 100644 --- a/src/util/u_string.h +++ b/src/util/u_string.h @@ -110,7 +110,10 @@ util_asprintf(char **str, const char *fmt, ...) return ret; } +#ifndef strcasecmp #define strcasecmp stricmp +#endif + #define strdup _strdup #endif -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] glx: Fix incompatible function pointer types.
I don't know how Meson didn't hit this issue, when it too already uses
-Werror=incompatible-pointer-types
---
src/mesa/drivers/x11/glxapi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/x11/glxapi.h b/src/mesa/drivers/x11/glxapi.h
index 90323a24731..6a1ce66a891 100644
--- a/src/mesa/drivers/x11/glxapi.h
+++ b/src/mesa/drivers/x11/glxapi.h
@@ -143,7 +143,7 @@ struct _glxapi_table {
/*** GLX_SGIX_pbuffer ***/
GLXPbufferSGIX (*CreateGLXPbufferSGIX)(Display *, GLXFBConfigSGIX, unsigned
int, unsigned int, int *);
void (*DestroyGLXPbufferSGIX)(Display *, GLXPbufferSGIX);
- int (*QueryGLXPbufferSGIX)(Display *, GLXPbufferSGIX, int, unsigned int *);
+ void (*QueryGLXPbufferSGIX)(Display *, GLXPbufferSGIX, int, unsigned int *);
void (*SelectEventSGIX)(Display *, GLXDrawable, unsigned long);
void (*GetSelectedEventSGIX)(Display *, GLXDrawable, unsigned long *);
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] util: Prevent implicit declaration of function getenv.
With MinGW cross compilation. --- src/util/os_misc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/util/os_misc.c b/src/util/os_misc.c index 755970430b0..436bc38604b 100644 --- a/src/util/os_misc.c +++ b/src/util/os_misc.c @@ -38,6 +38,7 @@ #endif #include #include +#include #else -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] panfrost: Don't use mir_foreach_instr_in_block_safe() when not needed
On Tue, 13 Aug 2019 15:30:20 -0700 Alyssa Rosenzweig wrote: > > I don't see any remove_ins()/insert_before() call in there. Do you see > > any reason for using the _safe() variant here? > > Er, I think I meant the outer loop, which has a remove/insert pair at > the bottom to change the current instruction. Should I apply this patch or do you prefer to keep using the _safe() variant even if it's not needed? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/5] panfrost: Rework midgard_pair_load_store() to kill the nested foreach loop
mir_foreach_instr_in_block_safe() is based on list_for_each_entry_safe()
which is designed to protect against removal of the current entry, but
removing the entry placed just after the current one will lead to a
use-after-free situation.
Luckily, the midgard_pair_load_store() logic guarantees that the
instruction being removed (if any) is never placed just after ins which
in turn guarantees that the hidden __next variable always points to a
valid object.
Took me a bit of time to realize that this code was safe, so I'm
suggesting to get rid of the inner mir_foreach_instr_in_block_from()
loop and rework the code so that the removed instruction is always the
current one (which is what the list_for_each_entry_safe() API was
initially designed for).
While at it, we also get rid of the unecessary insert(ins)/remove(ins)
dance by simply moving the instruction around.
Signed-off-by: Boris Brezillon
---
src/panfrost/midgard/midgard_schedule.c | 69 -
1 file changed, 32 insertions(+), 37 deletions(-)
diff --git a/src/panfrost/midgard/midgard_schedule.c
b/src/panfrost/midgard/midgard_schedule.c
index 57b0904cf007..1a22e683c3d3 100644
--- a/src/panfrost/midgard/midgard_schedule.c
+++ b/src/panfrost/midgard/midgard_schedule.c
@@ -606,46 +606,41 @@ schedule_block(compiler_context *ctx, midgard_block
*block)
static void
midgard_pair_load_store(compiler_context *ctx, midgard_block *block)
{
+midgard_instruction *prev_ldst = NULL;
+int search_distance;
+
mir_foreach_instr_in_block_safe(block, ins) {
-if (ins->type != TAG_LOAD_STORE_4) continue;
+if (ins->type != TAG_LOAD_STORE_4 && !prev_ldst) continue;
-/* We've found a load/store op. Check if next is also
load/store. */
-midgard_instruction *next_op = mir_next_op(ins);
-if (_op->link != >instructions) {
-if (next_op->type == TAG_LOAD_STORE_4) {
-/* If so, we're done since we're a pair */
-ins = mir_next_op(ins);
-continue;
-}
-
-/* Maximum search distance to pair, to avoid register
pressure disasters */
-int search_distance = 8;
-
-/* Otherwise, we have an orphaned load/store -- search
for another load */
-mir_foreach_instr_in_block_from(block, c,
mir_next_op(ins)) {
-/* Terminate search if necessary */
-if (!(search_distance--)) break;
-
-if (c->type != TAG_LOAD_STORE_4) continue;
-
-/* We can only reorder if there are no sources
*/
-
-bool deps = false;
-
-for (unsigned s = 0; s < ARRAY_SIZE(ins->src);
++s)
-deps |= (c->src[s] != ~0);
-
-if (deps)
-continue;
-
-/* We found one! Move it up to pair and remove
it from the old location */
-
-mir_insert_instruction_before(ins, *c);
-mir_remove_instruction(c);
-
-break;
-}
+/* We've found a load/store op. Start searching for another
one.
+ * Maximum search distance to pair, to avoid register pressure
disasters
+*/
+if (!prev_ldst) {
+search_distance = 8;
+prev_ldst = ins;
+continue;
}
+
+/* Already paired. */
+if (mir_prev_op(ins) == prev_ldst) {
+prev_ldst = NULL;
+continue;
+}
+
+/* We can only reorder if there are no sources */
+bool deps = false;
+for (unsigned s = 0; s < ARRAY_SIZE(ins->src); ++s)
+deps |= (ins->src[s] != ~0);
+
+/* We found one! Move it up to pair */
+if (!deps) {
+list_del(>link);
+list_add(>link, _ldst->link);
+continue;
+}
+
+if (!(search_distance--))
+prev_ldst = NULL;
}
}
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] panfrost: Free all block/instruction objects before leaving midgard_compile_shader_nir()
Right now we're leaking all block and instruction objects allocated by
the compiler. Let's clean things up before leaving
midgard_compile_shader_nir().
Signed-off-by: Boris Brezillon
---
src/panfrost/midgard/compiler.h| 12
src/panfrost/midgard/midgard_compile.c | 3 +++
2 files changed, 15 insertions(+)
diff --git a/src/panfrost/midgard/compiler.h b/src/panfrost/midgard/compiler.h
index f9ba31b5959d..d131bb8c1915 100644
--- a/src/panfrost/midgard/compiler.h
+++ b/src/panfrost/midgard/compiler.h
@@ -333,6 +333,9 @@ mir_next_op(struct midgard_instruction *ins)
#define mir_foreach_block(ctx, v) \
list_for_each_entry(struct midgard_block, v, >blocks, link)
+#define mir_foreach_block_safe(ctx, v) \
+list_for_each_entry_safe(struct midgard_block, v, >blocks, link)
+
#define mir_foreach_block_from(ctx, from, v) \
list_for_each_entry_from(struct midgard_block, v, from, >blocks,
link)
@@ -392,6 +395,15 @@ mir_next_op(struct midgard_instruction *ins)
#define mir_foreach_src(ins, v) \
for (unsigned v = 0; v < ARRAY_SIZE(ins->src); ++v)
+static inline void mir_remove_block(struct midgard_block *block)
+{
+mir_foreach_instr_in_block_safe(block, ins)
+mir_remove_instruction(ins);
+
+list_del(>link);
+free(block);
+}
+
static inline midgard_instruction *
mir_last_in_block(struct midgard_block *block)
{
diff --git a/src/panfrost/midgard/midgard_compile.c
b/src/panfrost/midgard/midgard_compile.c
index 74511b278d16..56a752433143 100644
--- a/src/panfrost/midgard/midgard_compile.c
+++ b/src/panfrost/midgard/midgard_compile.c
@@ -2835,6 +2835,9 @@ midgard_compile_shader_nir(struct midgard_screen *screen,
nir_shader *nir, midga
ctx->spills, ctx->fills);
}
+mir_foreach_block_safe(ctx, block)
+mir_remove_block(block);
+
ralloc_free(ctx);
return 0;
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] panfrost: Free the instruction object in mir_remove_instruction()
To avoid memory leaks.
Signed-off-by: Boris Brezillon
---
src/panfrost/midgard/compiler.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/panfrost/midgard/compiler.h b/src/panfrost/midgard/compiler.h
index 099d108142b1..f9ba31b5959d 100644
--- a/src/panfrost/midgard/compiler.h
+++ b/src/panfrost/midgard/compiler.h
@@ -315,6 +315,7 @@ static inline void
mir_remove_instruction(struct midgard_instruction *ins)
{
list_del(>link);
+free(ins);
}
static inline midgard_instruction*
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/5] panfrost: Make sure bundle.instructions[] contains valid instructions
Add an assert() in schedule_bundle() to make sure all instruction
pointers in bundle.instructions[] are valid.
Signed-off-by: Boris Brezillon
---
src/panfrost/midgard/midgard_schedule.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/panfrost/midgard/midgard_schedule.c
b/src/panfrost/midgard/midgard_schedule.c
index 1a22e683c3d3..f04a5c46a5dc 100644
--- a/src/panfrost/midgard/midgard_schedule.c
+++ b/src/panfrost/midgard/midgard_schedule.c
@@ -562,6 +562,7 @@ schedule_bundle(compiler_context *ctx, midgard_block
*block, midgard_instruction
midgard_instruction *uins = ins;
for (; packed_idx < bundle.instruction_count; ++packed_idx) {
+assert(>link != >instructions);
bundle.instructions[packed_idx] = uins;
uins = mir_next_op(uins);
}
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/5] panfrost: Fix a list_assert() in schedule_block()
list_for_each_entry() does not allow modifying the current item pointer.
Let's rework the skip-instructions logic in schedule_block() to not
break this rule.
Signed-off-by: Boris Brezillon
---
src/panfrost/midgard/midgard_schedule.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/panfrost/midgard/midgard_schedule.c
b/src/panfrost/midgard/midgard_schedule.c
index f80a0354fb88..57b0904cf007 100644
--- a/src/panfrost/midgard/midgard_schedule.c
+++ b/src/panfrost/midgard/midgard_schedule.c
@@ -581,8 +581,11 @@ schedule_block(compiler_context *ctx, midgard_block *block)
block->quadword_count = 0;
+int skip = 0;
mir_foreach_instr_in_block(block, ins) {
-int skip;
+if (skip--)
+continue;
+
midgard_bundle bundle = schedule_bundle(ctx, block, ins,
);
util_dynarray_append(>bundles, midgard_bundle, bundle);
@@ -592,9 +595,6 @@ schedule_block(compiler_context *ctx, midgard_block *block)
ctx->blend_constant_offset = quadwords_within_block *
0x10;
}
-while(skip--)
-ins = mir_next_op(ins);
-
block->quadword_count += quadword_size(bundle.tag);
}
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa GitLab <-> AppVeyor integration
FYI, I've followed Eric Engestroms' instructions for better Mesa <-> AppVeyor integration. (Thanks Eric.) I haven't tested, but hopefully this new integration method should now trigger Appveyor builds on pull requests too, which should come handy. I'm still keeping the old webhook method integration around (with a different name.) So the list might receive duplicate notifications. I'll disable this when we're satisfied the new method works well. For the record, these Appveyor runs are running on a separate Appveyor account dedicated for Mesa and FDO projects like Piglit, and not my personal Appveyor account. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] broadcom/vc4: Expand width of dst surface
On 27/8/19 11:13, Zhaowei Yuan wrote: Four bytes of src_surf will be compressed into a 32-bits data and stored into dst_surf, and dst_surf is read as z-order,so its width must be aligned to multiples of 8(4x2) before devided by 2. Signed-off-by: Zhaowei Yuan Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111266 --- src/gallium/drivers/vc4/vc4_blit.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/drivers/vc4/vc4_blit.c b/src/gallium/drivers/vc4/vc4_blit.c index d3cc515..7697bfa 100644 --- a/src/gallium/drivers/vc4/vc4_blit.c +++ b/src/gallium/drivers/vc4/vc4_blit.c @@ -361,6 +361,7 @@ vc4_yuv_blit(struct pipe_context *pctx, const struct pipe_blit_info *info) return false; } dst_surf->width /= 2; +dst_surf->width = align(dst_surf->width, 8) / 2; The commit message and what you are doing here is somewhat inconsistent, as you are dividing by two twice. Shouldn't the previous width division being replaced instead of adding a new aligned one? It is somewhat confusing to divide by two, and then align and divide by two again. FWIW, at this point it would be advisable if you send vc4/v3d patches as gitlab MR, as lately we are using it more that the mesa list. BR if (dst->cpp == 1) dst_surf->height /= 2; ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] broadcom/vc4: Expand width of dst surface
Four bytes of src_surf will be compressed into a 32-bits data and stored into dst_surf, and dst_surf is read as z-order,so its width must be aligned to multiples of 8(4x2) before devided by 2. Signed-off-by: Zhaowei Yuan Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111266 --- src/gallium/drivers/vc4/vc4_blit.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/drivers/vc4/vc4_blit.c b/src/gallium/drivers/vc4/vc4_blit.c index d3cc515..7697bfa 100644 --- a/src/gallium/drivers/vc4/vc4_blit.c +++ b/src/gallium/drivers/vc4/vc4_blit.c @@ -361,6 +361,7 @@ vc4_yuv_blit(struct pipe_context *pctx, const struct pipe_blit_info *info) return false; } dst_surf->width /= 2; +dst_surf->width = align(dst_surf->width, 8) / 2; if (dst->cpp == 1) dst_surf->height /= 2; -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] v3d: Difference between TransformFeedback Gallium <-> Vulkan
On 26/8/19 13:28, abergme...@gmx.net wrote: For a few weeks now I am working on implementing Vulkan for VideoCore 6 AKA 42 (using V3D/DRM). Don't hold you breath ;) Currently I am trying to understand what is necessary or how to interact with V3D. So I am looking at TransformFeedback because it interacts with quite a few other parts of the pipeline and still seems less mangled into the big logic than other features. So I am comparing how Gallium (V3D) is handling TF in the state tracker VS how Vulkan (Intel) is handling the Extension. The following is what I so far think I gathered: 1. GV3D is handling TransformFeedback directly with other bound parts of the pipeline (e.g. `emit_state` in _v3dx_emit.c_). It seems to look into the shader and associated TF specs. It seems to use "streamout targets", although I do not yet understand what these are really. Then it passes all the offsets, indices and finally resources to V3D. 2. The Vulkan Extension only knows about CounterBuffers and iterates over these. Intel seems to call TF -> XF? and subsequently the buffers XFB. Have also not yet gathered what is the difference and what all the gazillion acronyms mean. XFB is a really common acronym for transform feedback. So yes, XFB and TF are acronyms fro the same. So far my idea would be to implement TF similar to Intel and instead of iterating over "streamout targets" I would iterate XFBs. The problem with this approach is, that it will not be easy to mimic `cl_emit` calls similar to Gallium. My question now is which parts of V3D emits have a dependency. I would assume that I can move TRANSFORM_FEEDBACK_SPECS and TRANSFORM_FEEDBACK_ENABLE to cmd state flush in Vulkan. `vkCmdBeginTransformFeedbackEXT` shoudl then only need TRANSFORM_FEEDBACK_BUFFER and TRANSFORM_FEEDBACK_OUTPUT_ADDRESS. Sorry if this is a bit confusing - I am really just trying to figure this out one by one. Any information would be appreciated. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111493] In the game The Surge (378540) - textures disappear then appear again when I change the camera angle view
https://bugs.freedesktop.org/show_bug.cgi?id=111493 --- Comment #3 from Samuel Pitoiset --- 5544b2cbbd23df82192aea09d909b5cc2c1f1af9 is the first bad commit commit 5544b2cbbd23df82192aea09d909b5cc2c1f1af9 Author: Ian Romanick Date: Tue Jan 23 17:35:51 2018 +0800 nir/algebraic: Use value range analysis to eliminate useless unary ops Sandy Bridge is the big winner because it lies at something of a crossroads. It supports a fairly high OpenGL version, and it still has the old style math box. The high OpenGL version means a lot more shaders can run on it. The old style math box means extra moves are necessary to resolve source modifiers on operands to complex math instructions like COS, SQRT, and RCP. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111496] dEQP-GLES31.functional.shaders.builtin_functions.integer.umulextended.uint_highp_vertex fails with bad intrinsic
https://bugs.freedesktop.org/show_bug.cgi?id=111496
Bug ID: 111496
Summary: dEQP-GLES31.functional.shaders.builtin_functions.integ
er.umulextended.uint_highp_vertex fails with bad
intrinsic
Product: Mesa
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: not set
Priority: not set
Component: Drivers/Gallium/llvmpipe
Assignee: mesa-dev@lists.freedesktop.org
Reporter: airl...@freedesktop.org
QA Contact: mesa-dev@lists.freedesktop.org
Debug below:
llvm (version 0x800) found no intrinsic for llvm.x86.avx2.pmulu.dq, going to
crash...
On a skylake cpu.
llvmpipe: Fragment shader #131 variant #0:
FRAG
DCL IN[0].xy, GENERIC[9], CONSTANT
DCL OUT[0], COLOR
DCL OUT[1], COLOR[1]
0: MOV OUT[1].x, IN[0].
1: MOV OUT[0].x, IN[0].
2: END
fs variant 0x1f0f0bc:
cbuf_format[0] = PIPE_FORMAT_R32_UINT
cbuf_format[1] = PIPE_FORMAT_R32_UINT
blend.colormask = 0x1
variant->opaque = 0
; ModuleID = 'fs131_variant0'
source_filename = "fs131_variant0"
target datalayout = "e-p:64:64:64-i64:64:64-a0:0:64-s0:64:64"
; Function Attrs: nounwind readnone speculatable
declare <8 x float> @llvm.fmuladd.v8f32(<8 x float>, <8 x float>, <8 x float>)
#0
; Function Attrs: nounwind readnone
declare <8 x float> @llvm.x86.avx.min.ps.256(<8 x float>, <8 x float>) #1
; Function Attrs: nounwind readnone
declare <16 x i8> @llvm.x86.sse41.pblendvb(<16 x i8>, <16 x i8>, <16 x i8>) #1
define void @fs131_variant0_partial({ [16 x float*], [16 x i32], [128 x { i32,
i32, i32, i8*, [14 x i32], [14 x i32], i32, i32, [14 x i32] }], [32 x { float,
float, float, [4 x float] }], [32 x { i32, i32, i32, i8*, i32, i32 }], float,
i32, i32, i8*, float*, { float, float }*, [16 x i32*], [16 x i32] }* noalias
%context, i32 %x, i32 %y, i32, float* noalias %a0, float* noalias %dadx, float*
noalias %dady, <16 x i8>** noalias %color_ptr_ptr, i8* noalias %depth, i32
%mask_input, { { [2048 x i32], [128 x i64] }*, i64, i64, i32 }* noalias
%thread_data, i32* noalias %stride_ptr, i32 %depth_stride) {
entry:
%output16 = alloca <8 x float>
%output15 = alloca <8 x float>
%output14 = alloca <8 x float>
%output13 = alloca <8 x float>
%output12 = alloca <8 x float>
%output11 = alloca <8 x float>
%output10 = alloca <8 x float>
%output = alloca <8 x float>
%looplimiter = alloca i32
%execution_mask = alloca <8 x i32>
%color9 = alloca <8 x float>, i32 2
%color8 = alloca <8 x float>, i32 2
%color7 = alloca <8 x float>, i32 2
%color6 = alloca <8 x float>, i32 2
%color5 = alloca <8 x float>, i32 2
%color4 = alloca <8 x float>, i32 2
%color3 = alloca <8 x float>, i32 2
%color = alloca <8 x float>, i32 2
%loop_counter = alloca i32
%1 = alloca <8 x float>, i32 2
%2 = alloca <8 x float>, i32 2
%mask_store = alloca <8 x i32>, i32 2
%thread_data.invocs_ptr = getelementptr { { [2048 x i32], [128 x i64] }*,
i64, i64, i32 }, { { [2048 x i32], [128 x i64] }*, i64, i64, i32 }*
%thread_data, i32 0, i32 2
%3 = load i64, i64* %thread_data.invocs_ptr
%invoc_count = add i64 %3, 1
store i64 %invoc_count, i64* %thread_data.invocs_ptr
%4 = sitofp i32 %x to float
%5 = sitofp i32 %y to float
%6 = getelementptr <8 x float>, <8 x float>* %2, i32 0
store <8 x float> , <8 x float>* %6
%7 = getelementptr <8 x float>, <8 x float>* %1, i32 0
store <8 x float> , <8 x float>* %7
%8 = getelementptr <8 x float>, <8 x float>* %2, i32 1
store <8 x float> , <8 x float>* %8
%9 = getelementptr <8 x float>, <8 x float>* %1, i32 1
store <8 x float> , <8 x float>* %9
%10 = getelementptr float, float* %dadx, i32 0
%11 = bitcast float* %10 to <4 x float>*
%pos.x.dadxaos = load <4 x float>, <4 x float>* %11
%12 = getelementptr float, float* %dady, i32 0
%13 = bitcast float* %12 to <4 x float>*
%pos.x.dadyaos = load <4 x float>, <4 x float>* %13
%14 = getelementptr float, float* %a0, i32 0
%15 = bitcast float* %14 to <4 x float>*
%pos.x.a0aos = load <4 x float>, <4 x float>* %15
%16 = getelementptr float, float* %a0, i32 4
%17 = bitcast float* %16 to <4 x float>*
%input0.x.a0aos = load <4 x float>, <4 x float>* %17
%mask_ptr = getelementptr <8 x i32>, <8 x i32>* %mask_store, i32 0
%18 = lshr i32 %mask_input, 0
%19 = insertelement <8 x i32> undef, i32 %18, i32 0
%20 = shufflevector <8 x i32> %19, <8 x i32> undef, <8 x i32> zeroinitializer
%21 = and <8 x i32> %20,
%22 = icmp eq <8 x i32> %21,
%23 = sext <8 x i1> %22 to <8 x i32>
store <8 x i32> %23, <8 x i32>* %mask_ptr
%mask_ptr1 = getelementptr <8 x i32>, <8 x i32>* %mask_store, i32 1
%24 = lshr i32 %mask_input, 8
%25 = insertelement <8 x i32> undef, i32 %24, i32 0
%26 = shufflevector <8 x i32> %25, <8 x i32> undef, <8 x i32> zeroinitializer
%27 = and <8 x i32> %26,
%28 = icmp eq <8 x i32> %27,
%29 = sext <8 x i1> %28 to <8 x i32>
store <8 x i32>
[Mesa-dev] [Bug 111493] In the game The Surge (378540) - textures disappear then appear again when I change the camera angle view
https://bugs.freedesktop.org/show_bug.cgi?id=111493 --- Comment #2 from Samuel Pitoiset --- Works perfectly fine with Mesa 19.1.5. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111493] In the game The Surge (378540) - textures disappear then appear again when I change the camera angle view
https://bugs.freedesktop.org/show_bug.cgi?id=111493 --- Comment #1 from Samuel Pitoiset --- I can reproduce this, is this something recent for you? I think that game used to work in the past. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Navi14 for 19.2
ACK. On 8/26/19 9:05 PM, Marek Olšák wrote: Hi, I'd like to push the Navi14 merge request to 19.2 no later than Tuesday August 27. https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1726 Please ack if it's OK with you, Thanks, Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
