[Mesa-dev] [Bug 111511] integer cube sampling fails to build shader
https://bugs.freedesktop.org/show_bug.cgi?id=111511 Dave Airlie changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Dave Airlie --- Adding texture gather component support fixes the rest of the deqp tests, https://gitlab.freedesktop.org/airlied/mesa/tree/llvmpipe-gles31-wip has the fixes (the gather component is a bit messy to pipe through). I'll close this since it's fixed. -- 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
Re: [Mesa-dev] [PATCH] egl/android: Enable HAL_PIXEL_FORMAT_RGBA_FP16 format
Thanks for the patch and review, merged!
On Thu, Aug 29, 2019 at 3:45 AM Tapani Pälli wrote:
>
> Reviewed-by: Tapani Pälli
>
> On 8/29/19 12:18 AM, Nataraj Deshpande wrote:
> > The patch adds support for 64 bit HAL_PIXEL_FORMAT_RGBA_FP16
> > for android platform.
> >
> > Fixes android.graphics.cts.BitmapColorSpaceTest#test16bitHardware
> > which failed in egl due to "Unsupported native buffer format 0x16"
> > on chromebooks.
> >
> > Change-Id: I44f886fce27fe5f738d2dc229eed8b59088cf6d6
> > Signed-off-by: Nataraj Deshpande
> > ---
> > src/egl/drivers/dri2/platform_android.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/src/egl/drivers/dri2/platform_android.c
> > b/src/egl/drivers/dri2/platform_android.c
> > index 601b29e..97e7947 100644
> > --- a/src/egl/drivers/dri2/platform_android.c
> > +++ b/src/egl/drivers/dri2/platform_android.c
> > @@ -109,6 +109,9 @@ get_format_bpp(int native)
> > int bpp;
> >
> > switch (native) {
> > + case HAL_PIXEL_FORMAT_RGBA_FP16:
> > + bpp = 8;
> > + break;
> > case HAL_PIXEL_FORMAT_RGBA_:
> > case HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED:
> > /*
> > @@ -143,6 +146,7 @@ static int get_fourcc(int native)
> > * TODO: Remove this once https://issuetracker.google.com/32077885
> > is fixed.
> > */
> > case HAL_PIXEL_FORMAT_RGBX_: return __DRI_IMAGE_FOURCC_XBGR;
> > + case HAL_PIXEL_FORMAT_RGBA_FP16: return
> > __DRI_IMAGE_FOURCC_ABGR16161616F;
> > default:
> > _eglLog(_EGL_WARNING, "unsupported native buffer format 0x%x",
> > native);
> > }
> > @@ -161,6 +165,7 @@ static int get_format(int format)
> > * TODO: Revert this once https://issuetracker.google.com/32077885
> > is fixed.
> > */
> > case HAL_PIXEL_FORMAT_RGBX_: return __DRI_IMAGE_FORMAT_XBGR;
> > + case HAL_PIXEL_FORMAT_RGBA_FP16: return
> > __DRI_IMAGE_FORMAT_ABGR16161616F;
> > default:
> > _eglLog(_EGL_WARNING, "unsupported native buffer format 0x%x",
> > format);
> > }
> >
> ___
> 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 111511] integer cube sampling fails to build shader
https://bugs.freedesktop.org/show_bug.cgi?id=111511 --- Comment #7 from Roland Scheidegger --- Ahh so it might not pass for other reasons. -- 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] Mesa 19.2.0 release plan
On 7/8/19 10:44, Emil Velikov wrote: Hi all, Hi Emil, On Wed, 31 Jul 2019 at 09:37, Emil Velikov wrote: Hi all, Here is the tentative release plan for 19.2.0. As many of you are well aware, it's time to the next branch point. The calendar is already updated, so these are the tentative dates: Aug 06 2019 - Feature freeze/Release candidate 1 Aug 13 2019 - Release candidate 2 Aug 20 2019 - Release candidate 3 Aug 27 2019 - Release candidate 4/final release With multiple teams finalising the final features for their drivers, I've decided to push the branch point by one week. Are we still in time to add this v3d patch: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1818 It is not still on master, but I would try to get it merged on master tomorrow Friday. But if there isn't any possibility to get it included on 19.2.X at this point, I would not bother anyone to get an extra Rb/Ack. Thanks in advance, and sorry if at this point the answer is evident I would like to remind teams that they are welcome to merge functionality early and keep it disabled by default. This way they can address outstanding issues and enable, during the stabilisation period. Thanks Emil ___ 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 111523] Clover - radeonsi: Mesa git - broken compilation with current LLVM 10.0.0
https://bugs.freedesktop.org/show_bug.cgi?id=111523
Bug ID: 111523
Summary: Clover - radeonsi: Mesa git - broken compilation with
current LLVM 10.0.0
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: critical
Priority: not set
Component: Gallium/StateTracker/Clover
Assignee: mesa-dev@lists.freedesktop.org
Reporter: die...@nuetzel-hh.de
QA Contact: mesa-dev@lists.freedesktop.org
../src/gallium/state_trackers/clover/llvm/invocation.cpp: In function
‘std::unique_ptr
{anonymous}::create_compiler_instance(const clover::device&, const
std::vector >&, std::string&)’:
../src/gallium/state_trackers/clover/llvm/invocation.cpp:203:81: error: no
matching function for call to
‘clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, const
char* const*, const char* const*, clang::DiagnosticsEngine&)’
203 | c->getInvocation(), copts.data(), copts.data() +
copts.size(), diag))
|
^
In file included from /usr/local/include/clang/Frontend/CompilerInstance.h:15,
from ../src/gallium/state_trackers/clover/llvm/codegen.hpp:37,
from
../src/gallium/state_trackers/clover/llvm/invocation.cpp:49:
/usr/local/include/clang/Frontend/CompilerInvocation.h:157:15: note: candidate:
‘static bool
clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&,
llvm::ArrayRef, clang::DiagnosticsEngine&)’
157 | static bool CreateFromArgs(CompilerInvocation ,
| ^~
/usr/local/include/clang/Frontend/CompilerInvocation.h:157:15: note:
candidate expects 3 arguments, 4 provided
../src/gallium/state_trackers/clover/llvm/invocation.cpp: In function
‘std::unique_ptr {anonymous}::link(llvm::LLVMContext&, const
clang::CompilerInstance&, const std::vector&, std::string&)’:
../src/gallium/state_trackers/clover/llvm/invocation.cpp:360:23: warning:
moving a local object in a return statement prevents copy elision
[-Wpessimizing-move]
360 | return std::move(mod);
| ~^
../src/gallium/state_trackers/clover/llvm/invocation.cpp:360:23: note: remove
‘std::move’ call
--
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 111511] integer cube sampling fails to build shader
https://bugs.freedesktop.org/show_bug.cgi?id=111511 --- Comment #6 from Dave Airlie --- GLES 3.1 needs some enhanced gather paths so I think we are just missing some of those. -- 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 111511] integer cube sampling fails to build shader
https://bugs.freedesktop.org/show_bug.cgi?id=111511 --- Comment #5 from Dave Airlie --- We fail a bunch of gather tests integer and non-integer with deqp Some of the below, I haven't had a chance to dig into the fail list yet, I wanted to fix all the assert crashes first. dEQP-GLES31.functional.texture.gather.basic.2d.rgba8.size_pot.clamp_to_edge_repeat,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8.size_pot.repeat_mirrored_repeat,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8.size_pot.mirrored_repeat_clamp_to_edge,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8.size_npot.clamp_to_edge_repeat,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8.size_npot.repeat_mirrored_repeat,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8.size_npot.mirrored_repeat_clamp_to_edge,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8.texture_swizzle.red_green_blue_alpha,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8.texture_swizzle.green_blue_alpha_zero,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8.texture_swizzle.blue_alpha_zero_one,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8.texture_swizzle.alpha_zero_one_red,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8.texture_swizzle.zero_one_red_green,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8.texture_swizzle.one_red_green_blue,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8.filter_mode.min_linear_mag_linear,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8.filter_mode.min_nearest_mipmap_nearest_mag_linear,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8.filter_mode.min_nearest_mipmap_linear_mag_linear,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8.filter_mode.min_linear_mipmap_nearest_mag_linear,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8.filter_mode.min_linear_mipmap_linear_mag_linear,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8.base_level.level_1,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8.base_level.level_2,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8.incomplete.mipmap_incomplete,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8ui.size_pot.clamp_to_edge_repeat,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8ui.size_pot.repeat_mirrored_repeat,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8ui.size_pot.mirrored_repeat_clamp_to_edge,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8ui.size_npot.clamp_to_edge_repeat,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8ui.size_npot.repeat_mirrored_repeat,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8ui.size_npot.mirrored_repeat_clamp_to_edge,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8ui.texture_swizzle.red_green_blue_alpha,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8ui.texture_swizzle.green_blue_alpha_zero,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8ui.texture_swizzle.blue_alpha_zero_one,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8ui.texture_swizzle.alpha_zero_one_red,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8ui.texture_swizzle.zero_one_red_green,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8ui.texture_swizzle.one_red_green_blue,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8ui.filter_mode.min_nearest_mipmap_nearest_mag_nearest,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8ui.base_level.level_1,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8ui.base_level.level_2,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8i.size_pot.clamp_to_edge_repeat,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8i.size_pot.repeat_mirrored_repeat,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8i.size_pot.mirrored_repeat_clamp_to_edge,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8i.size_npot.clamp_to_edge_repeat,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8i.size_npot.repeat_mirrored_repeat,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8i.size_npot.mirrored_repeat_clamp_to_edge,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8i.texture_swizzle.red_green_blue_alpha,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8i.texture_swizzle.green_blue_alpha_zero,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8i.texture_swizzle.blue_alpha_zero_one,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8i.texture_swizzle.alpha_zero_one_red,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8i.texture_swizzle.zero_one_red_green,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8i.texture_swizzle.one_red_green_blue,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8i.filter_mode.min_nearest_mipmap_nearest_mag_nearest,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8i.base_level.level_1,Fail dEQP-GLES31.functional.texture.gather.basic.2d.rgba8i.base_level.level_2,Fail
Re: [Mesa-dev] Switching to Gitlab Issues instead of Bugzilla?
Kenneth Graunke writes: > [ Unknown signature status ] > Hi all, > > As a lot of you have probably noticed, Bugzilla seems to be getting a > lot of spam these days - several of us have been disabling a bunch of > accounts per day, sweeping new reports under the rug, hiding comments, > etc. This bug spam causes emails to be sent (more spam!) and then us > to have to look at ancient bugs that suddenly have updates. > > I think it's probably time to consider switching away from Bugzilla. > We are one of the few projects remaining - Mesa, DRM, and a few DDX > drivers are still there, but almost all other projects are gone: > > https://bugs.freedesktop.org/enter_bug.cgi > > Originally, I was in favor of retaining Bugzilla just to not change too > many processes all at once. But we've been using Gitlab a while now, > and several of us have been using Gitlab issues in our personal repos; > it's actually pretty nice. Yes, please. I haven't been participating in bugzilla, in favor of personal github and krh's mesa gitlab. 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] gallivm: disable accurate cube corner for integer textures.
Am 29.08.19 um 22:06 schrieb Dave Airlie: > From: Dave Airlie > > Bugzilla: > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freedesktop.org%2Fshow_bug.cgi%3Fid%3D111511data=02%7C01%7Csroland%40vmware.com%7Cfec452f1a7bc48fdf26c08d72cbc7631%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637027060290077242sdata=DIFdJJllTfLtwIYd5GJVUNmCx9ecNrNKRrbSg9qkMy8%3Dreserved=0 > --- > src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c > b/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c > index adb6adf143a..69dba78ac8a 100644 > --- a/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c > +++ b/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c > @@ -1039,6 +1039,10 @@ lp_build_sample_image_linear(struct > lp_build_sample_context *bld, > > accurate_cube_corners = ACCURATE_CUBE_CORNERS && seamless_cube_filter; > > + /* disable accurate cube corners for integer textures. */ > + if (is_gather && > util_format_is_pure_integer(bld->static_texture_state->format)) > + accurate_cube_corners = FALSE; I think should drop the is_gather condition - it would crash all the same if it ends up here (which it shouldn't as the texture would be incomplete in this case). So just accurate_cube_corners = ACCURATE_CUBE_CORNERS && seamless_cube_filter && !util_format_is_pure_integer() (maybe with a comment that we should only end up with the linear image path here in case of gather). With that fixed, Reviewed-by: Roland Scheidegger > lp_build_extract_image_sizes(bld, > >int_size_bld, > bld->int_coord_type, > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111511] integer cube sampling fails to build shader
https://bugs.freedesktop.org/show_bug.cgi?id=111511 --- Comment #4 from Roland Scheidegger --- (In reply to Dave Airlie from comment #3) > I've sent a patch to disable accurate cube corners for integer textures to > the list. > > It doesn't fix the test but it stops it asserting, which means I can > complete a deqp gles31 run without dying. So what does the test expect? I'm kind of curious what the result should be, since I'd be a bit surprised if the missing texel ought to really be interpolated with the other 3 texel colors. Yes gl spec suggests this but I don't think this is really meant for integer textures. In any case gl doesn't actually mandate anything specific for this texel, even with ordinary filtering. -- 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 111510] [gallium-nine] [build failure] change in clang CompilerInvocation::CreateFromArgs breaks build
https://bugs.freedesktop.org/show_bug.cgi?id=111510 --- Comment #1 from Axel Davy --- Gallium-nine doesn't use llvm directly. It uses it possibly through radeonsi or llvmpipe. I assume you get the same problem when building mesa without gallium nine ? Could you tell if the problem is when compiling radeonsi files or llvmpipe files ? Thanks -- 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] Switching to Gitlab Issues instead of Bugzilla?
Quoting Kristian Høgsberg (2019-08-29 21:20:12) > On Thu, Aug 29, 2019 at 12:44 PM Chris Wilson > wrote: > > > > Quoting Kenneth Graunke (2019-08-29 19:52:51) > > > Some cons: > > > > > > - Moving bug reports between the kernel and Mesa would be harder. > > > We would have to open a bug in the other system. (Then again, > > > moving bugs between Mesa and X or Wayland would be easier...) > > > > All that I ask is that we move the kernel bugzilla along with it. Trying > > to keep abreast of the bugs in the whole stack is important. Fwiw, the > > kernel contains the https:bugs.freedesktop.org/enter_bug.cgi?product=DRI > > URL so would need some redirection for a few years... > > Would Rob's suggestion of creating a placeholder drm kernel repo for > the purpose of issue tracking work for you? I think so. I just want a list of all bugs that may affect the code I'm working on, wherever they were filed. I have a search in bugs.fdo, I just need instructions on how to get the same from gitlab, hopefully in a compact format. The issue URL will also need to be stable so that we can include it in commits. From a glance, https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/861, looks like it will be adjusted if it ever gets moved. -Chris ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Switching to Gitlab Issues instead of Bugzilla?
On Thu, Aug 29, 2019 at 12:44 PM Chris Wilson wrote: > > Quoting Kenneth Graunke (2019-08-29 19:52:51) > > Some cons: > > > > - Moving bug reports between the kernel and Mesa would be harder. > > We would have to open a bug in the other system. (Then again, > > moving bugs between Mesa and X or Wayland would be easier...) > > All that I ask is that we move the kernel bugzilla along with it. Trying > to keep abreast of the bugs in the whole stack is important. Fwiw, the > kernel contains the https:bugs.freedesktop.org/enter_bug.cgi?product=DRI > URL so would need some redirection for a few years... Would Rob's suggestion of creating a placeholder drm kernel repo for the purpose of issue tracking work for you? Kristian > -Chris > ___ > 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 111511] integer cube sampling fails to build shader
https://bugs.freedesktop.org/show_bug.cgi?id=111511 --- Comment #3 from Dave Airlie --- I've sent a patch to disable accurate cube corners for integer textures to the list. It doesn't fix the test but it stops it asserting, which means I can complete a deqp gles31 run without dying. -- 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] [PATCH] gallivm: disable accurate cube corner for integer textures.
From: Dave Airlie Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111511 --- src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c | 4 1 file changed, 4 insertions(+) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c b/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c index adb6adf143a..69dba78ac8a 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c +++ b/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c @@ -1039,6 +1039,10 @@ lp_build_sample_image_linear(struct lp_build_sample_context *bld, accurate_cube_corners = ACCURATE_CUBE_CORNERS && seamless_cube_filter; + /* disable accurate cube corners for integer textures. */ + if (is_gather && util_format_is_pure_integer(bld->static_texture_state->format)) + accurate_cube_corners = FALSE; + lp_build_extract_image_sizes(bld, >int_size_bld, bld->int_coord_type, -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Switching to Gitlab Issues instead of Bugzilla?
Quoting Kenneth Graunke (2019-08-29 19:52:51) > Some cons: > > - Moving bug reports between the kernel and Mesa would be harder. > We would have to open a bug in the other system. (Then again, > moving bugs between Mesa and X or Wayland would be easier...) All that I ask is that we move the kernel bugzilla along with it. Trying to keep abreast of the bugs in the whole stack is important. Fwiw, the kernel contains the https:bugs.freedesktop.org/enter_bug.cgi?product=DRI URL so would need some redirection for a few years... -Chris ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Switching to Gitlab Issues instead of Bugzilla?
+1 On Thu, Aug 29, 2019 at 2:36 PM Rob Clark wrote: > On Thu, Aug 29, 2019 at 12:02 PM Kenneth Graunke > wrote: > > > > Hi all, > > > > As a lot of you have probably noticed, Bugzilla seems to be getting a > > lot of spam these days - several of us have been disabling a bunch of > > accounts per day, sweeping new reports under the rug, hiding comments, > > etc. This bug spam causes emails to be sent (more spam!) and then us > > to have to look at ancient bugs that suddenly have updates. > > > > I think it's probably time to consider switching away from Bugzilla. > > We are one of the few projects remaining - Mesa, DRM, and a few DDX > > drivers are still there, but almost all other projects are gone: > > > > https://bugs.freedesktop.org/enter_bug.cgi > > > > Originally, I was in favor of retaining Bugzilla just to not change too > > many processes all at once. But we've been using Gitlab a while now, > > and several of us have been using Gitlab issues in our personal repos; > > it's actually pretty nice. > > > > Some niceities: > > > > - Bug reporters don't necessarily need to sign up for an account > > anymore. They can sign in with their Gitlab.com, Github, Google, > > or Twitter accounts. Or make one as before. This may be nicer for > > reporters that don't want to open yet another account just to report > > an issue to us. > > > > - Anti-spam support is actually maintained. Bugzilla makes it near > > impossible to actually delete garbage, Gitlab makes it easier. It > > has a better account creation hurdle than Bugzilla's ancient captcha, > > and Akismet plug-ins for handling spam. > > > > - The search interface is more modern and easier to use IMO. > > > > - Permissions & accounts are easier - it's the same unified system. > > > > - Easy linking between issues and MRs - mention one in the other, and > > both get updated with cross-links so you don't miss any discussion. > > > > - Milestone tracking > > > > - This could be handy for release trackers - both features people > > want to land, and bugs blocking the release. > > > > - We could also use it for big efforts like direct state access, > > getting feature parity with fglrx, or whatnot. > > > > - Khronos switched a while ago as well, so a number of us are already > > familiar with using it there. > > > > Some cons: > > > > - Moving bug reports between the kernel and Mesa would be harder. > > We would have to open a bug in the other system. (Then again, > > moving bugs between Mesa and X or Wayland would be easier...) > > If that was a concern, we could setup a kernel gitlab project that has > an empty git repository (at least until we are ready to move drm git > tree). > > > What do people think? If folks are in favor, Daniel can migrate > > everything for us, like he did with the other projects. If not, > > I'd like to hear what people's concerns are. > > > > yes, please, let's move! > > BR, > -R > ___ > 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] Switching to Gitlab Issues instead of Bugzilla?
On Thu, Aug 29, 2019 at 12:02 PM Kenneth Graunke wrote: > > Hi all, > > As a lot of you have probably noticed, Bugzilla seems to be getting a > lot of spam these days - several of us have been disabling a bunch of > accounts per day, sweeping new reports under the rug, hiding comments, > etc. This bug spam causes emails to be sent (more spam!) and then us > to have to look at ancient bugs that suddenly have updates. > > I think it's probably time to consider switching away from Bugzilla. > We are one of the few projects remaining - Mesa, DRM, and a few DDX > drivers are still there, but almost all other projects are gone: > > https://bugs.freedesktop.org/enter_bug.cgi > > Originally, I was in favor of retaining Bugzilla just to not change too > many processes all at once. But we've been using Gitlab a while now, > and several of us have been using Gitlab issues in our personal repos; > it's actually pretty nice. > > Some niceities: > > - Bug reporters don't necessarily need to sign up for an account > anymore. They can sign in with their Gitlab.com, Github, Google, > or Twitter accounts. Or make one as before. This may be nicer for > reporters that don't want to open yet another account just to report > an issue to us. > > - Anti-spam support is actually maintained. Bugzilla makes it near > impossible to actually delete garbage, Gitlab makes it easier. It > has a better account creation hurdle than Bugzilla's ancient captcha, > and Akismet plug-ins for handling spam. > > - The search interface is more modern and easier to use IMO. > > - Permissions & accounts are easier - it's the same unified system. > > - Easy linking between issues and MRs - mention one in the other, and > both get updated with cross-links so you don't miss any discussion. > > - Milestone tracking > > - This could be handy for release trackers - both features people > want to land, and bugs blocking the release. > > - We could also use it for big efforts like direct state access, > getting feature parity with fglrx, or whatnot. > > - Khronos switched a while ago as well, so a number of us are already > familiar with using it there. > > Some cons: > > - Moving bug reports between the kernel and Mesa would be harder. > We would have to open a bug in the other system. (Then again, > moving bugs between Mesa and X or Wayland would be easier...) If that was a concern, we could setup a kernel gitlab project that has an empty git repository (at least until we are ready to move drm git tree). > What do people think? If folks are in favor, Daniel can migrate > everything for us, like he did with the other projects. If not, > I'd like to hear what people's concerns are. > yes, please, let's move! BR, -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Switching to Gitlab Issues instead of Bugzilla?
On Thu, Aug 29, 2019 at 12:02 PM Kenneth Graunke wrote: > > Hi all, > > As a lot of you have probably noticed, Bugzilla seems to be getting a > lot of spam these days - several of us have been disabling a bunch of > accounts per day, sweeping new reports under the rug, hiding comments, > etc. This bug spam causes emails to be sent (more spam!) and then us > to have to look at ancient bugs that suddenly have updates. > > I think it's probably time to consider switching away from Bugzilla. > We are one of the few projects remaining - Mesa, DRM, and a few DDX > drivers are still there, but almost all other projects are gone: > > https://bugs.freedesktop.org/enter_bug.cgi > > Originally, I was in favor of retaining Bugzilla just to not change too > many processes all at once. But we've been using Gitlab a while now, > and several of us have been using Gitlab issues in our personal repos; > it's actually pretty nice. > > Some niceities: > > - Bug reporters don't necessarily need to sign up for an account > anymore. They can sign in with their Gitlab.com, Github, Google, > or Twitter accounts. Or make one as before. This may be nicer for > reporters that don't want to open yet another account just to report > an issue to us. > > - Anti-spam support is actually maintained. Bugzilla makes it near > impossible to actually delete garbage, Gitlab makes it easier. It > has a better account creation hurdle than Bugzilla's ancient captcha, > and Akismet plug-ins for handling spam. > > - The search interface is more modern and easier to use IMO. > > - Permissions & accounts are easier - it's the same unified system. > > - Easy linking between issues and MRs - mention one in the other, and > both get updated with cross-links so you don't miss any discussion. > > - Milestone tracking > > - This could be handy for release trackers - both features people > want to land, and bugs blocking the release. > > - We could also use it for big efforts like direct state access, > getting feature parity with fglrx, or whatnot. > > - Khronos switched a while ago as well, so a number of us are already > familiar with using it there. > > Some cons: > > - Moving bug reports between the kernel and Mesa would be harder. > We would have to open a bug in the other system. (Then again, > moving bugs between Mesa and X or Wayland would be easier...) > > What do people think? If folks are in favor, Daniel can migrate > everything for us, like he did with the other projects. If not, > I'd like to hear what people's concerns are. Definitely in favor here. We've been using it for tracking freedreno issues over in my gitlab mesa, but would much prefer to use the main repo. Kristian > --Ken > ___ > 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] Switching to Gitlab Issues instead of Bugzilla?
Hi all, As a lot of you have probably noticed, Bugzilla seems to be getting a lot of spam these days - several of us have been disabling a bunch of accounts per day, sweeping new reports under the rug, hiding comments, etc. This bug spam causes emails to be sent (more spam!) and then us to have to look at ancient bugs that suddenly have updates. I think it's probably time to consider switching away from Bugzilla. We are one of the few projects remaining - Mesa, DRM, and a few DDX drivers are still there, but almost all other projects are gone: https://bugs.freedesktop.org/enter_bug.cgi Originally, I was in favor of retaining Bugzilla just to not change too many processes all at once. But we've been using Gitlab a while now, and several of us have been using Gitlab issues in our personal repos; it's actually pretty nice. Some niceities: - Bug reporters don't necessarily need to sign up for an account anymore. They can sign in with their Gitlab.com, Github, Google, or Twitter accounts. Or make one as before. This may be nicer for reporters that don't want to open yet another account just to report an issue to us. - Anti-spam support is actually maintained. Bugzilla makes it near impossible to actually delete garbage, Gitlab makes it easier. It has a better account creation hurdle than Bugzilla's ancient captcha, and Akismet plug-ins for handling spam. - The search interface is more modern and easier to use IMO. - Permissions & accounts are easier - it's the same unified system. - Easy linking between issues and MRs - mention one in the other, and both get updated with cross-links so you don't miss any discussion. - Milestone tracking - This could be handy for release trackers - both features people want to land, and bugs blocking the release. - We could also use it for big efforts like direct state access, getting feature parity with fglrx, or whatnot. - Khronos switched a while ago as well, so a number of us are already familiar with using it there. Some cons: - Moving bug reports between the kernel and Mesa would be harder. We would have to open a bug in the other system. (Then again, moving bugs between Mesa and X or Wayland would be easier...) What do people think? If folks are in favor, Daniel can migrate everything for us, like he did with the other projects. If not, I'd like to hear what people's concerns are. --Ken signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] panfrost: Remove unused variable from panfrost_drm_submit_vs_fs_job
On Thu, 29 Aug 2019 15:31:31 +0200 Rohan Garg wrote: > On jueves, 29 de agosto de 2019 15:07:08 (CEST) Boris Brezillon wrote: > > On Thu, 29 Aug 2019 14:53:10 +0200 > > > > Rohan Garg wrote: > > > is_scanout is not used anywhere and can be inferred within > > > panfrost_drm_submit_vs_fs_job if required. > > > > Signed-off-by tag is missing. Looks good otherwise. > > > > Signed-off-by: Rohan Garg Queued to master. Thanks, Boris ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111511] integer cube sampling fails to build shader
https://bugs.freedesktop.org/show_bug.cgi?id=111511 --- Comment #2 from Roland Scheidegger --- I forgot to mention, I have no idea what the fourth texel should be in case of cube corners for integer textures. As said I highly doubt averaging is the answer, but apart from that no idea. Hopefully though a randomly selected texel from the other 3 is good enough... I don't think this is mentioned anywhere in the spec (and for d3d it doesn't really apply since integer textures are supposed to only be fetched, sample/gather is not really legal although might work). -- 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
[Mesa-dev] [Bug 111511] integer cube sampling fails to build shader
https://bugs.freedesktop.org/show_bug.cgi?id=111511 --- Comment #1 from Roland Scheidegger --- I don't think averaging would be correct for integer cube corners (as integer textures generally perform no lerp on values). I think the problem here is the forcing of linear filtering paths for gather ops (see beginning of lp_build_sample_soa_code() code) doesn't quite work here - this is done because gather is nearly the same as linear filtering as far as texel selection goes usually, just without the filter in general, so making the code easier. Perhaps the code needs to recognize the texture is integer and simply skip the accurate_cube_corners code if the texture is integer (this should only happen in the is_gather case in any case, since otherwise we should never end up in the sample_image_linear path for integer textures). -- 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
[Mesa-dev] [Bug 111522] [bisected] Supraland no longer start
https://bugs.freedesktop.org/show_bug.cgi?id=111522 Bug ID: 111522 Summary: [bisected] Supraland no longer start Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: not set Component: Drivers/Vulkan/Common Assignee: mesa-dev@lists.freedesktop.org Reporter: megwa...@gmail.com CC: airl...@freedesktop.org, chadvers...@chromium.org, ja...@jlekstrand.net Commit 9653d80de187fe9d9e5211b475065e7e09598f19 break Supraland (UE 4.21 vulkan game). The game only show a black window which is closed after roughly 1 minute. Tested on a RX 570. A demo of the game is freely available if needed. Culprit commit: 9653d80de187fe9d9e5211b475065e7e09598f19 Author: Bas Nieuwenhuizen Date: Mon May 20 22:58:32 2019 +0200 vulkan/wsi/x11: Increase the effective min. images for mailbox. We need 5 images: 1) CPU work 2) GPU work 3) idle 4) queued for flip 5) presenting Reviewed-by: Lionel Landwerlin -- 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] panfrost/ci: Print only regressions
A-b On Thu, Aug 29, 2019 at 04:15:32PM +0200, Tomeu Vizoso wrote: > Some functionality has been added to deqp-volt to only print > regressions, so update our version of it and use the new options. > > Signed-off-by: Tomeu Vizoso > --- > src/gallium/drivers/panfrost/ci/deqp-runner.sh | 9 ++--- > src/gallium/drivers/panfrost/ci/gitlab-ci.yml | 2 +- > 2 files changed, 7 insertions(+), 4 deletions(-) > > diff --git a/src/gallium/drivers/panfrost/ci/deqp-runner.sh > b/src/gallium/drivers/panfrost/ci/deqp-runner.sh > index c6b2cce88829..b226c3d3e6f6 100644 > --- a/src/gallium/drivers/panfrost/ci/deqp-runner.sh > +++ b/src/gallium/drivers/panfrost/ci/deqp-runner.sh > @@ -95,11 +95,14 @@ for test in $FLIP_FLOPS; do sed -i "/$test/d" > /tmp/case-list.txt; done > --results-file=/tmp/results.txt \ > --no-passed-results \ > --regression-file=/deqp/expected-failures.txt \ > ---no-rerun-tests > +--no-rerun-tests \ > +--print-regression \ > +--no-print-fail \ > +--no-print-quality \ > +--no-colour-term > > if [ $? -ne 0 ]; then > -echo "Regressions detected, printing results:" > -cat /tmp/results.txt > +echo "Regressions detected" > echo "deqp: fail" > else > echo "No regressions detected" > diff --git a/src/gallium/drivers/panfrost/ci/gitlab-ci.yml > b/src/gallium/drivers/panfrost/ci/gitlab-ci.yml > index 8bbb48ab76f1..ed0123b00a91 100644 > --- a/src/gallium/drivers/panfrost/ci/gitlab-ci.yml > +++ b/src/gallium/drivers/panfrost/ci/gitlab-ci.yml > @@ -16,7 +16,7 @@ > variables: >UPSTREAM_REPO: mesa/mesa >DEBIAN_VERSION: testing-slim > - IMAGE_TAG: "2019-08-21-1" > + IMAGE_TAG: "2019-08-29-1" > > include: >- project: 'wayland/ci-templates' > -- > 2.20.1 > signature.asc Description: PGP signature ___ 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 Roland Scheidegger changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Roland Scheidegger --- Fixed by 332b21db55e6e6ec777b940f1b95843010d22157 -- 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] [PATCH] gallivm: use fallback code for mul_hi with llvm >= 7.0
Am 29.08.19 um 15:05 schrieb Jose Fonseca:
> This change is
>
> Reviewed-by: Jose Fonseca
>
> Regarding follow up change, do you think the LLVM pattern is sane/doable?
Yes, should be doable and not too bad (I did not verify that what we're
doing doesn't actually get recognized, since it's theoretically possible
some other lowering could produce the pattern, although it seems unlikely).
I think though this code isn't hit a lot - it was once used by draw,
which is why I noticed the suboptimal code generated and added the
optimized version, but nowadays it's just for mulhi, so should be fairly
rare in practice.
>
> If not we should try ask them to reconsider relying strictly upon
> pattern matching. I get the feeling upstream LLVM is throwing the baby
> with the water with these changes. I do understand the advantages of
> moving away from vendor specific intrinsics, but I think that for things
> which have no natural representation on LLVM base IR, they should add a
> vendor-agnostic intrinsic, for example a new "/llvm.mulhi.*" set of
> instrinsics/, as narrow pattern matching is bound to produce performance
> cliffs nobody will notice.
They did add new generic intrinsics for some things, but not this one
indeed.
I'm not exactly a big fan of this pattern matching in favor of
intrinsics neither, at least if the patterns are non-trivial...
Roland
> /
> /
> /Jose/
>
>
> *From:* srol...@vmware.com
> *Sent:* Wednesday, August 28, 2019 20:37
> *To:* mesa-dev@lists.freedesktop.org ;
> Jose Fonseca ; airl...@freedesktop.org
>
> *Cc:* Roland Scheidegger
> *Subject:* [PATCH] gallivm: use fallback code for mul_hi with llvm >= 7.0
>
> From: Roland Scheidegger
>
> LLVM 7.0 ditched the pmulu intrinsics.
> This is only a trivial patch to use the fallback code instead.
> It'll likely produce atrocious code since the pattern doesn't match what
> llvm itself uses in its autoupgrade paths, hence the pattern won't be
> recognized.
>
> Should fix https://bugs.freedesktop.org/show_bug.cgi?id=111496
> ---
> src/gallium/auxiliary/gallivm/lp_bld_arit.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> index c4931c0b230..f1866c6625f 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> @@ -1169,8 +1169,13 @@ lp_build_mul_32_lohi_cpu(struct lp_build_context
> *bld,
> * https://llvm.org/bugs/show_bug.cgi?id=30845
> * So, whip up our own code, albeit only for length 4 and 8 (which
> * should be good enough)...
> + * FIXME: For llvm >= 7.0 we should match the autoupgrade pattern
> + * (bitcast/and/mul/shuffle for unsigned, bitcast/shl/ashr/mul/shuffle
> + * for signed), which the fallback code does not, without this llvm
> + * will likely still produce atrocious code.
> */
> - if ((bld->type.length == 4 || bld->type.length == 8) &&
> + if (HAVE_LLVM < 0x0700 &&
> + (bld->type.length == 4 || bld->type.length == 8) &&
> ((util_cpu_caps.has_sse2 && (bld->type.sign == 0)) ||
> util_cpu_caps.has_sse4_1)) {
> const char *intrinsic = NULL;
> --
> 2.17.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH RFC 1/2] dri: Let drivers reset the damage region
On Thu, 29 Aug 2019 13:54:15 +0200
Boris Brezillon wrote:
> dri2_set_damage_region() must call st_validate_state(UPDATE_FRAMEBUFFER)
> to make sure the BACK_LEFT attachment is up-to-date.
> Problem is, dri2_swap_buffers_xxx() functions are actually targeting
> the old backbuffer when they call ->set_damage_region(0, NULL), and
> more importantly, they are not expecting the caller to pull a new back
> buffer at this point, which will happen if st_validate_state() is
> called.
>
> Let's delegate the damage region reset to drivers (they should take
> care of that at flush/swap time) so we don't have to deal with this
> extra complexity at the EGL level.
>
> The only gallium driver implementing ->set_damage_region() is patched
> accordingly.
>
> Signed-off-by: Boris Brezillon
> ---
> include/GL/internal/dri_interface.h | 4
> src/egl/drivers/dri2/egl_dri2.c | 24 -
> src/gallium/drivers/panfrost/pan_context.c | 14 +++-
> src/gallium/drivers/panfrost/pan_resource.c | 2 +-
> src/gallium/drivers/panfrost/pan_resource.h | 2 ++
> 5 files changed, 20 insertions(+), 26 deletions(-)
>
> diff --git a/include/GL/internal/dri_interface.h
> b/include/GL/internal/dri_interface.h
> index 4b5583820ed0..4c60d349ddd5 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -521,6 +521,10 @@ struct __DRI2bufferDamageExtensionRec {
> * reset the region, followed by a second call with a populated region,
> * before a rendering call is made.
> *
> +* Drivers implementing this entrypoint should take care of resetting the
> +* damage region of resources being written to at swapbuffer/flush time.
> +* The DRI core will not automate that for you.
> +*
> * Used to implement EGL_KHR_partial_update.
> *
> * \param drawable affected drawable
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
> index 526cb1969c18..ea8ae5d44c56 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -1767,7 +1767,6 @@ static EGLBoolean
> dri2_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp, _EGLSurface *surf)
> {
> struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
> - __DRIdrawable *dri_drawable = dri2_dpy->vtbl->get_dri_drawable(surf);
> _EGLContext *ctx = _eglGetCurrentContext();
> EGLBoolean ret;
>
> @@ -1775,13 +1774,6 @@ dri2_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp,
> _EGLSurface *surf)
>dri2_surf_update_fence_fd(ctx, disp, surf);
> ret = dri2_dpy->vtbl->swap_buffers(drv, disp, surf);
>
> - /* SwapBuffers marks the end of the frame; reset the damage region for
> -* use again next time.
> -*/
> - if (ret && dri2_dpy->buffer_damage &&
> - dri2_dpy->buffer_damage->set_damage_region)
> - dri2_dpy->buffer_damage->set_damage_region(dri_drawable, 0, NULL);
> -
> return ret;
> }
>
> @@ -1791,7 +1783,6 @@ dri2_swap_buffers_with_damage(_EGLDriver *drv,
> _EGLDisplay *disp,
>const EGLint *rects, EGLint n_rects)
> {
> struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
> - __DRIdrawable *dri_drawable = dri2_dpy->vtbl->get_dri_drawable(surf);
> _EGLContext *ctx = _eglGetCurrentContext();
> EGLBoolean ret;
>
> @@ -1800,13 +1791,6 @@ dri2_swap_buffers_with_damage(_EGLDriver *drv,
> _EGLDisplay *disp,
> ret = dri2_dpy->vtbl->swap_buffers_with_damage(drv, disp, surf,
>rects, n_rects);
>
> - /* SwapBuffers marks the end of the frame; reset the damage region for
> -* use again next time.
> -*/
> - if (ret && dri2_dpy->buffer_damage &&
> - dri2_dpy->buffer_damage->set_damage_region)
> - dri2_dpy->buffer_damage->set_damage_region(dri_drawable, 0, NULL);
> -
> return ret;
> }
>
> @@ -1815,18 +1799,10 @@ dri2_swap_buffers_region(_EGLDriver *drv, _EGLDisplay
> *disp, _EGLSurface *surf,
> EGLint numRects, const EGLint *rects)
> {
> struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
> - __DRIdrawable *dri_drawable = dri2_dpy->vtbl->get_dri_drawable(surf);
> EGLBoolean ret;
>
> ret = dri2_dpy->vtbl->swap_buffers_region(drv, disp, surf, numRects,
> rects);
>
> - /* SwapBuffers marks the end of the frame; reset the damage region for
> -* use again next time.
> -*/
> - if (ret && dri2_dpy->buffer_damage &&
> - dri2_dpy->buffer_damage->set_damage_region)
> - dri2_dpy->buffer_damage->set_damage_region(dri_drawable, 0, NULL);
> -
> return ret;
> }
>
> diff --git a/src/gallium/drivers/panfrost/pan_context.c
> b/src/gallium/drivers/panfrost/pan_context.c
> index fa9c92af9f6a..4069ec238fe4 100644
> --- a/src/gallium/drivers/panfrost/pan_context.c
> +++ b/src/gallium/drivers/panfrost/pan_context.c
> @@ -1461,7 +1461,8 @@ panfrost_flush(
> struct
[Mesa-dev] [PATCH] panfrost/ci: Print only regressions
Some functionality has been added to deqp-volt to only print regressions, so update our version of it and use the new options. Signed-off-by: Tomeu Vizoso --- src/gallium/drivers/panfrost/ci/deqp-runner.sh | 9 ++--- src/gallium/drivers/panfrost/ci/gitlab-ci.yml | 2 +- 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/src/gallium/drivers/panfrost/ci/deqp-runner.sh b/src/gallium/drivers/panfrost/ci/deqp-runner.sh index c6b2cce88829..b226c3d3e6f6 100644 --- a/src/gallium/drivers/panfrost/ci/deqp-runner.sh +++ b/src/gallium/drivers/panfrost/ci/deqp-runner.sh @@ -95,11 +95,14 @@ for test in $FLIP_FLOPS; do sed -i "/$test/d" /tmp/case-list.txt; done --results-file=/tmp/results.txt \ --no-passed-results \ --regression-file=/deqp/expected-failures.txt \ ---no-rerun-tests +--no-rerun-tests \ +--print-regression \ +--no-print-fail \ +--no-print-quality \ +--no-colour-term if [ $? -ne 0 ]; then -echo "Regressions detected, printing results:" -cat /tmp/results.txt +echo "Regressions detected" echo "deqp: fail" else echo "No regressions detected" diff --git a/src/gallium/drivers/panfrost/ci/gitlab-ci.yml b/src/gallium/drivers/panfrost/ci/gitlab-ci.yml index 8bbb48ab76f1..ed0123b00a91 100644 --- a/src/gallium/drivers/panfrost/ci/gitlab-ci.yml +++ b/src/gallium/drivers/panfrost/ci/gitlab-ci.yml @@ -16,7 +16,7 @@ variables: UPSTREAM_REPO: mesa/mesa DEBIAN_VERSION: testing-slim - IMAGE_TAG: "2019-08-21-1" + IMAGE_TAG: "2019-08-29-1" include: - project: 'wayland/ci-templates' -- 2.20.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH RFC 2/2] dri: Pass a __DRIcontext to ->set_damage_region()
On Thu, 29 Aug 2019 13:54:16 +0200 Boris Brezillon
said:
These 2 do improve things, but once you start doing BindFramebuffer()'s as part
of the render cycle ... its back to rendering artifacts. I am not quite sure
exactly what yet. I need to capture some output and traces to get a better idea
of what is going on.
> So we can call st_validate_state() from dri2_set_damage_region() in
> order to update the BACK_LEFT attachement before using it. If we don't
> do that, the resource passed to pipe_screen->set_damage_region() might
> be wrong.
>
> Signed-off-by: Boris Brezillon
> ---
> Hi,
>
> I honestly don't know if this is the right thing to do. Passing a
> context for somethings that we decided to bind to a surface (and
> the underlying resources attached to it) seems wrong, but at the same
> time I don't see any other option to sync the gallium drawable state
> with the EGL DRI surface one.
>
> Any ideas/suggestions?
>
> Regards,
>
> Boris
> ---
> include/GL/internal/dri_interface.h | 5 +++--
> src/egl/drivers/dri2/egl_dri2.c | 7 +--
> src/gallium/state_trackers/dri/dri2.c | 11 ++-
> 3 files changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/include/GL/internal/dri_interface.h
> b/include/GL/internal/dri_interface.h index 4c60d349ddd5..e04bed689219 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -527,12 +527,13 @@ struct __DRI2bufferDamageExtensionRec {
> *
> * Used to implement EGL_KHR_partial_update.
> *
> +* \param ctx context
> * \param drawable affected drawable
> * \param nrects number of rectangles provided
> * \param rectsthe array of rectangles, lower-left origin
> */
> - void (*set_damage_region)(__DRIdrawable *drawable, unsigned int nrects,
> - int *rects);
> + void (*set_damage_region)(__DRIcontext *_ctx, __DRIdrawable *drawable,
> + unsigned int nrects, int *rects);
> };
>
> /*@}*/
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
> index ea8ae5d44c56..797a76dab13c 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -1812,11 +1812,14 @@ dri2_set_damage_region(_EGLDriver *drv, _EGLDisplay
> *disp, _EGLSurface *surf, {
> struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
> __DRIdrawable *drawable = dri2_dpy->vtbl->get_dri_drawable(surf);
> + _EGLContext *ctx = _eglGetCurrentContext();
> + __DRIcontext *dri_ctx = ctx ? dri2_egl_context(ctx)->dri_context : NULL;
>
> - if (!dri2_dpy->buffer_damage || !
> dri2_dpy->buffer_damage->set_damage_region)
> + if (!dri2_dpy->buffer_damage || !
> dri2_dpy->buffer_damage->set_damage_region ||
> + !dri_ctx)
>return EGL_FALSE;
>
> - dri2_dpy->buffer_damage->set_damage_region(drawable, n_rects, rects);
> + dri2_dpy->buffer_damage->set_damage_region(dri_ctx, drawable, n_rects,
> rects); return EGL_TRUE;
> }
>
> diff --git a/src/gallium/state_trackers/dri/dri2.c
> b/src/gallium/state_trackers/dri/dri2.c index 11ce19787249..bab503046510
> 100644
> --- a/src/gallium/state_trackers/dri/dri2.c
> +++ b/src/gallium/state_trackers/dri/dri2.c
> @@ -36,6 +36,7 @@
> #include "util/u_format.h"
> #include "util/u_debug.h"
> #include "state_tracker/drm_driver.h"
> +#include "state_tracker/st_atom.h"
> #include "state_tracker/st_cb_bufferobjects.h"
> #include "state_tracker/st_cb_fbo.h"
> #include "state_tracker/st_cb_texture.h"
> @@ -1869,9 +1870,17 @@ static const __DRI2interopExtension
> dri2InteropExtension = {
> * \brief the DRI2bufferDamageExtension set_damage_region method
> */
> static void
> -dri2_set_damage_region(__DRIdrawable *dPriv, unsigned int nrects, int *rects)
> +dri2_set_damage_region(__DRIcontext *_ctx, __DRIdrawable *dPriv,
> + unsigned int nrects, int *rects)
> {
> struct dri_drawable *drawable = dri_drawable(dPriv);
> + struct st_context *st = (struct st_context *)dri_context(_ctx)->st;
> +
> + /* Make sure drawable->textures[ST_ATTACHMENT_BACK_LEFT] is up-to-date
> +* before using it.
> +*/
> + st_validate_state(st, ST_PIPELINE_UPDATE_FRAMEBUFFER);
> +
> struct pipe_resource *resource =
> drawable->textures[ST_ATTACHMENT_BACK_LEFT]; struct pipe_screen *screen =
> resource->screen; struct pipe_box *boxes = NULL;
> --
> 2.21.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] panfrost: Remove unused variable from panfrost_drm_submit_vs_fs_job
On jueves, 29 de agosto de 2019 15:07:08 (CEST) Boris Brezillon wrote: > On Thu, 29 Aug 2019 14:53:10 +0200 > > Rohan Garg wrote: > > is_scanout is not used anywhere and can be inferred within > > panfrost_drm_submit_vs_fs_job if required. > > Signed-off-by tag is missing. Looks good otherwise. > Signed-off-by: Rohan Garg signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] panfrost: Remove unused variable from panfrost_drm_submit_vs_fs_job
On Thu, 29 Aug 2019 14:53:10 +0200
Rohan Garg wrote:
> is_scanout is not used anywhere and can be inferred within
> panfrost_drm_submit_vs_fs_job if required.
Signed-off-by tag is missing. Looks good otherwise.
Reviewed-by: Boris Brezillon
> ---
> src/gallium/drivers/panfrost/pan_drm.c| 2 +-
> src/gallium/drivers/panfrost/pan_job.c| 3 +--
> src/gallium/drivers/panfrost/pan_screen.h | 3 +--
> 3 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/drivers/panfrost/pan_drm.c
> b/src/gallium/drivers/panfrost/pan_drm.c
> index c3693bff56a..8e05fc936b2 100644
> --- a/src/gallium/drivers/panfrost/pan_drm.c
> +++ b/src/gallium/drivers/panfrost/pan_drm.c
> @@ -292,7 +292,7 @@ panfrost_drm_submit_job(struct panfrost_context *ctx, u64
> job_desc, int reqs)
> }
>
> int
> -panfrost_drm_submit_vs_fs_job(struct panfrost_context *ctx, bool has_draws,
> bool is_scanout)
> +panfrost_drm_submit_vs_fs_job(struct panfrost_context *ctx, bool has_draws)
> {
> int ret = 0;
>
> diff --git a/src/gallium/drivers/panfrost/pan_job.c
> b/src/gallium/drivers/panfrost/pan_job.c
> index 4d8ec2eadc9..f5bbd04b913 100644
> --- a/src/gallium/drivers/panfrost/pan_job.c
> +++ b/src/gallium/drivers/panfrost/pan_job.c
> @@ -208,9 +208,8 @@ panfrost_job_submit(struct panfrost_context *ctx, struct
> panfrost_job *job)
> panfrost_scoreboard_link_batch(job);
>
> bool has_draws = job->last_job.gpu;
> -bool is_scanout = panfrost_is_scanout(ctx);
>
> -ret = panfrost_drm_submit_vs_fs_job(ctx, has_draws, is_scanout);
> +ret = panfrost_drm_submit_vs_fs_job(ctx, has_draws);
>
> if (ret)
> fprintf(stderr, "panfrost_job_submit failed: %d\n", ret);
> diff --git a/src/gallium/drivers/panfrost/pan_screen.h
> b/src/gallium/drivers/panfrost/pan_screen.h
> index 35fb8de2628..02e8a96fabe 100644
> --- a/src/gallium/drivers/panfrost/pan_screen.h
> +++ b/src/gallium/drivers/panfrost/pan_screen.h
> @@ -165,8 +165,7 @@ panfrost_drm_import_bo(struct panfrost_screen *screen,
> int fd);
> int
> panfrost_drm_export_bo(struct panfrost_screen *screen, const struct
> panfrost_bo *bo);
> int
> -panfrost_drm_submit_vs_fs_job(struct panfrost_context *ctx, bool has_draws,
> - bool is_scanout);
> +panfrost_drm_submit_vs_fs_job(struct panfrost_context *ctx, bool has_draws);
> void
> panfrost_drm_force_flush_fragment(struct panfrost_context *ctx,
>struct pipe_fence_handle **fence);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallivm: use fallback code for mul_hi with llvm >= 7.0
This change is
Reviewed-by: Jose Fonseca
Regarding follow up change, do you think the LLVM pattern is sane/doable?
If not we should try ask them to reconsider relying strictly upon pattern
matching. I get the feeling upstream LLVM is throwing the baby with the water
with these changes. I do understand the advantages of moving away from vendor
specific intrinsics, but I think that for things which have no natural
representation on LLVM base IR, they should add a vendor-agnostic intrinsic,
for example a new "llvm.mulhi.*" set of instrinsics, as narrow pattern
matching is bound to produce performance cliffs nobody will notice.
Jose
From: srol...@vmware.com
Sent: Wednesday, August 28, 2019 20:37
To: mesa-dev@lists.freedesktop.org ; Jose
Fonseca ; airl...@freedesktop.org
Cc: Roland Scheidegger
Subject: [PATCH] gallivm: use fallback code for mul_hi with llvm >= 7.0
From: Roland Scheidegger
LLVM 7.0 ditched the pmulu intrinsics.
This is only a trivial patch to use the fallback code instead.
It'll likely produce atrocious code since the pattern doesn't match what
llvm itself uses in its autoupgrade paths, hence the pattern won't be
recognized.
Should fix https://bugs.freedesktop.org/show_bug.cgi?id=111496
---
src/gallium/auxiliary/gallivm/lp_bld_arit.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
index c4931c0b230..f1866c6625f 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
@@ -1169,8 +1169,13 @@ lp_build_mul_32_lohi_cpu(struct lp_build_context *bld,
* https://llvm.org/bugs/show_bug.cgi?id=30845
* So, whip up our own code, albeit only for length 4 and 8 (which
* should be good enough)...
+* FIXME: For llvm >= 7.0 we should match the autoupgrade pattern
+* (bitcast/and/mul/shuffle for unsigned, bitcast/shl/ashr/mul/shuffle
+* for signed), which the fallback code does not, without this llvm
+* will likely still produce atrocious code.
*/
- if ((bld->type.length == 4 || bld->type.length == 8) &&
+ if (HAVE_LLVM < 0x0700 &&
+ (bld->type.length == 4 || bld->type.length == 8) &&
((util_cpu_caps.has_sse2 && (bld->type.sign == 0)) ||
util_cpu_caps.has_sse4_1)) {
const char *intrinsic = NULL;
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] panfrost: Jobs must be per context, not per screen
On Thu, 29 Aug 2019 14:51:52 +0200
Rohan Garg wrote:
> Jobs _must_ only be shared across the same context, having
> the last_job tracked in a screen causes use-after-free issues
> and memory corruptions.
You should probably also mention that transient-pool and bo-cache
related fields should be protected by a mutex as they are shared by all
contexts. Or even better, split that patch in 2:
1/ move last_job, last_fragment_pushed to panfrost_context
2/ protect transient/bo-cache manipulation with mutexes
>
> Signed-off-by: Rohan Garg
> ---
> src/gallium/drivers/panfrost/pan_allocate.c | 2 ++
> src/gallium/drivers/panfrost/pan_bo_cache.c | 16 +++-
> src/gallium/drivers/panfrost/pan_context.c | 10 +-
> src/gallium/drivers/panfrost/pan_context.h | 6 ++
> src/gallium/drivers/panfrost/pan_drm.c | 6 +++---
> src/gallium/drivers/panfrost/pan_job.c | 2 ++
> src/gallium/drivers/panfrost/pan_screen.c | 5 ++---
> src/gallium/drivers/panfrost/pan_screen.h | 10 --
> 8 files changed, 35 insertions(+), 22 deletions(-)
>
> diff --git a/src/gallium/drivers/panfrost/pan_allocate.c
> b/src/gallium/drivers/panfrost/pan_allocate.c
> index f549c864c70..fb8b18fe718 100644
> --- a/src/gallium/drivers/panfrost/pan_allocate.c
> +++ b/src/gallium/drivers/panfrost/pan_allocate.c
> @@ -74,6 +74,7 @@ panfrost_allocate_transient(struct panfrost_context *ctx,
> size_t sz)
> unsigned offset = 0;
> bool update_offset = false;
>
> +pthread_mutex_lock(>transient_lock);
> bool has_current = batch->transient_indices.size;
> bool fits_in_current = (batch->transient_offset + sz) <
> TRANSIENT_SLAB_SIZE;
>
> @@ -131,6 +132,7 @@ panfrost_allocate_transient(struct panfrost_context *ctx,
> size_t sz)
>
> if (update_offset)
> batch->transient_offset = offset + sz;
> +pthread_mutex_unlock(>transient_lock);
>
> return ret;
>
> diff --git a/src/gallium/drivers/panfrost/pan_bo_cache.c
> b/src/gallium/drivers/panfrost/pan_bo_cache.c
> index 9dd6b694b72..f2f49437a89 100644
> --- a/src/gallium/drivers/panfrost/pan_bo_cache.c
> +++ b/src/gallium/drivers/panfrost/pan_bo_cache.c
> @@ -24,6 +24,7 @@
> * Alyssa Rosenzweig
> */
> #include
> +#include
> #include "drm-uapi/panfrost_drm.h"
>
> #include "pan_screen.h"
> @@ -84,7 +85,9 @@ panfrost_bo_cache_fetch(
> struct panfrost_screen *screen,
> size_t size, uint32_t flags)
> {
> +pthread_mutex_lock(>bo_cache_lock);
> struct list_head *bucket = pan_bucket(screen, size);
> +struct panfrost_bo *bo = NULL;
>
> /* Iterate the bucket looking for something suitable */
> list_for_each_entry_safe(struct panfrost_bo, entry, bucket, link) {
> @@ -106,12 +109,13 @@ panfrost_bo_cache_fetch(
> continue;
> }
> /* Let's go! */
> -return entry;
> +bo = entry;
> +break;
> }
> }
> +pthread_mutex_unlock(>bo_cache_lock);
>
> -/* We didn't find anything */
> -return NULL;
> +return bo;
> }
>
> /* Tries to add a BO to the cache. Returns if it was
> @@ -122,6 +126,7 @@ panfrost_bo_cache_put(
> struct panfrost_screen *screen,
> struct panfrost_bo *bo)
> {
> +pthread_mutex_lock(>bo_cache_lock);
> struct list_head *bucket = pan_bucket(screen, bo->size);
> struct drm_panfrost_madvise madv;
>
> @@ -133,6 +138,7 @@ panfrost_bo_cache_put(
>
> /* Add us to the bucket */
> list_addtail(>link, bucket);
> +pthread_mutex_unlock(>bo_cache_lock);
>
> return true;
> }
> @@ -147,6 +153,7 @@ void
> panfrost_bo_cache_evict_all(
> struct panfrost_screen *screen)
> {
> +pthread_mutex_lock(>bo_cache_lock);
> for (unsigned i = 0; i < ARRAY_SIZE(screen->bo_cache); ++i) {
> struct list_head *bucket = >bo_cache[i];
>
> @@ -155,7 +162,6 @@ panfrost_bo_cache_evict_all(
> panfrost_drm_release_bo(screen, entry, false);
> }
> }
> -
> -return;
> +pthread_mutex_unlock(>bo_cache_lock);
> }
>
> diff --git a/src/gallium/drivers/panfrost/pan_context.c
> b/src/gallium/drivers/panfrost/pan_context.c
> index fa9c92af9f6..94ee9b5bdb2 100644
> --- a/src/gallium/drivers/panfrost/pan_context.c
> +++ b/src/gallium/drivers/panfrost/pan_context.c
> @@ -1329,9 +1329,6 @@ panfrost_submit_frame(struct panfrost_context *ctx,
> bool flush_immediate,
>struct pipe_fence_handle **fence,
>struct panfrost_job *job)
> {
> -struct pipe_context *gallium = (struct pipe_context *) ctx;
> -struct panfrost_screen *screen =
[Mesa-dev] [PATCH] panfrost: Remove unused variable from panfrost_drm_submit_vs_fs_job
is_scanout is not used anywhere and can be inferred within
panfrost_drm_submit_vs_fs_job if required.
---
src/gallium/drivers/panfrost/pan_drm.c| 2 +-
src/gallium/drivers/panfrost/pan_job.c| 3 +--
src/gallium/drivers/panfrost/pan_screen.h | 3 +--
3 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_drm.c
b/src/gallium/drivers/panfrost/pan_drm.c
index c3693bff56a..8e05fc936b2 100644
--- a/src/gallium/drivers/panfrost/pan_drm.c
+++ b/src/gallium/drivers/panfrost/pan_drm.c
@@ -292,7 +292,7 @@ panfrost_drm_submit_job(struct panfrost_context *ctx, u64
job_desc, int reqs)
}
int
-panfrost_drm_submit_vs_fs_job(struct panfrost_context *ctx, bool has_draws,
bool is_scanout)
+panfrost_drm_submit_vs_fs_job(struct panfrost_context *ctx, bool has_draws)
{
int ret = 0;
diff --git a/src/gallium/drivers/panfrost/pan_job.c
b/src/gallium/drivers/panfrost/pan_job.c
index 4d8ec2eadc9..f5bbd04b913 100644
--- a/src/gallium/drivers/panfrost/pan_job.c
+++ b/src/gallium/drivers/panfrost/pan_job.c
@@ -208,9 +208,8 @@ panfrost_job_submit(struct panfrost_context *ctx, struct
panfrost_job *job)
panfrost_scoreboard_link_batch(job);
bool has_draws = job->last_job.gpu;
-bool is_scanout = panfrost_is_scanout(ctx);
-ret = panfrost_drm_submit_vs_fs_job(ctx, has_draws, is_scanout);
+ret = panfrost_drm_submit_vs_fs_job(ctx, has_draws);
if (ret)
fprintf(stderr, "panfrost_job_submit failed: %d\n", ret);
diff --git a/src/gallium/drivers/panfrost/pan_screen.h
b/src/gallium/drivers/panfrost/pan_screen.h
index 35fb8de2628..02e8a96fabe 100644
--- a/src/gallium/drivers/panfrost/pan_screen.h
+++ b/src/gallium/drivers/panfrost/pan_screen.h
@@ -165,8 +165,7 @@ panfrost_drm_import_bo(struct panfrost_screen *screen, int
fd);
int
panfrost_drm_export_bo(struct panfrost_screen *screen, const struct
panfrost_bo *bo);
int
-panfrost_drm_submit_vs_fs_job(struct panfrost_context *ctx, bool has_draws,
- bool is_scanout);
+panfrost_drm_submit_vs_fs_job(struct panfrost_context *ctx, bool has_draws);
void
panfrost_drm_force_flush_fragment(struct panfrost_context *ctx,
struct pipe_fence_handle **fence);
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] panfrost: Jobs must be per context, not per screen
Jobs _must_ only be shared across the same context, having
the last_job tracked in a screen causes use-after-free issues
and memory corruptions.
Signed-off-by: Rohan Garg
---
src/gallium/drivers/panfrost/pan_allocate.c | 2 ++
src/gallium/drivers/panfrost/pan_bo_cache.c | 16 +++-
src/gallium/drivers/panfrost/pan_context.c | 10 +-
src/gallium/drivers/panfrost/pan_context.h | 6 ++
src/gallium/drivers/panfrost/pan_drm.c | 6 +++---
src/gallium/drivers/panfrost/pan_job.c | 2 ++
src/gallium/drivers/panfrost/pan_screen.c | 5 ++---
src/gallium/drivers/panfrost/pan_screen.h | 10 --
8 files changed, 35 insertions(+), 22 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_allocate.c
b/src/gallium/drivers/panfrost/pan_allocate.c
index f549c864c70..fb8b18fe718 100644
--- a/src/gallium/drivers/panfrost/pan_allocate.c
+++ b/src/gallium/drivers/panfrost/pan_allocate.c
@@ -74,6 +74,7 @@ panfrost_allocate_transient(struct panfrost_context *ctx,
size_t sz)
unsigned offset = 0;
bool update_offset = false;
+pthread_mutex_lock(>transient_lock);
bool has_current = batch->transient_indices.size;
bool fits_in_current = (batch->transient_offset + sz) <
TRANSIENT_SLAB_SIZE;
@@ -131,6 +132,7 @@ panfrost_allocate_transient(struct panfrost_context *ctx,
size_t sz)
if (update_offset)
batch->transient_offset = offset + sz;
+pthread_mutex_unlock(>transient_lock);
return ret;
diff --git a/src/gallium/drivers/panfrost/pan_bo_cache.c
b/src/gallium/drivers/panfrost/pan_bo_cache.c
index 9dd6b694b72..f2f49437a89 100644
--- a/src/gallium/drivers/panfrost/pan_bo_cache.c
+++ b/src/gallium/drivers/panfrost/pan_bo_cache.c
@@ -24,6 +24,7 @@
* Alyssa Rosenzweig
*/
#include
+#include
#include "drm-uapi/panfrost_drm.h"
#include "pan_screen.h"
@@ -84,7 +85,9 @@ panfrost_bo_cache_fetch(
struct panfrost_screen *screen,
size_t size, uint32_t flags)
{
+pthread_mutex_lock(>bo_cache_lock);
struct list_head *bucket = pan_bucket(screen, size);
+struct panfrost_bo *bo = NULL;
/* Iterate the bucket looking for something suitable */
list_for_each_entry_safe(struct panfrost_bo, entry, bucket, link) {
@@ -106,12 +109,13 @@ panfrost_bo_cache_fetch(
continue;
}
/* Let's go! */
-return entry;
+bo = entry;
+break;
}
}
+pthread_mutex_unlock(>bo_cache_lock);
-/* We didn't find anything */
-return NULL;
+return bo;
}
/* Tries to add a BO to the cache. Returns if it was
@@ -122,6 +126,7 @@ panfrost_bo_cache_put(
struct panfrost_screen *screen,
struct panfrost_bo *bo)
{
+pthread_mutex_lock(>bo_cache_lock);
struct list_head *bucket = pan_bucket(screen, bo->size);
struct drm_panfrost_madvise madv;
@@ -133,6 +138,7 @@ panfrost_bo_cache_put(
/* Add us to the bucket */
list_addtail(>link, bucket);
+pthread_mutex_unlock(>bo_cache_lock);
return true;
}
@@ -147,6 +153,7 @@ void
panfrost_bo_cache_evict_all(
struct panfrost_screen *screen)
{
+pthread_mutex_lock(>bo_cache_lock);
for (unsigned i = 0; i < ARRAY_SIZE(screen->bo_cache); ++i) {
struct list_head *bucket = >bo_cache[i];
@@ -155,7 +162,6 @@ panfrost_bo_cache_evict_all(
panfrost_drm_release_bo(screen, entry, false);
}
}
-
-return;
+pthread_mutex_unlock(>bo_cache_lock);
}
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index fa9c92af9f6..94ee9b5bdb2 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -1329,9 +1329,6 @@ panfrost_submit_frame(struct panfrost_context *ctx, bool
flush_immediate,
struct pipe_fence_handle **fence,
struct panfrost_job *job)
{
-struct pipe_context *gallium = (struct pipe_context *) ctx;
-struct panfrost_screen *screen = pan_screen(gallium->screen);
-
panfrost_job_submit(ctx, job);
/* If visual, we can stall a frame */
@@ -1339,8 +1336,8 @@ panfrost_submit_frame(struct panfrost_context *ctx, bool
flush_immediate,
if (!flush_immediate)
panfrost_drm_force_flush_fragment(ctx, fence);
-screen->last_fragment_flushed = false;
-screen->last_job = job;
+ctx->last_fragment_flushed = false;
+ctx->last_job = job;
/* If readback, flush now (hurts the pipelined performance) */
if (flush_immediate)
@@ -2856,6 +2853,9 @@
[Mesa-dev] [PATCH RFC 1/2] dri: Let drivers reset the damage region
dri2_set_damage_region() must call st_validate_state(UPDATE_FRAMEBUFFER)
to make sure the BACK_LEFT attachment is up-to-date.
Problem is, dri2_swap_buffers_xxx() functions are actually targeting
the old backbuffer when they call ->set_damage_region(0, NULL), and
more importantly, they are not expecting the caller to pull a new back
buffer at this point, which will happen if st_validate_state() is
called.
Let's delegate the damage region reset to drivers (they should take
care of that at flush/swap time) so we don't have to deal with this
extra complexity at the EGL level.
The only gallium driver implementing ->set_damage_region() is patched
accordingly.
Signed-off-by: Boris Brezillon
---
include/GL/internal/dri_interface.h | 4
src/egl/drivers/dri2/egl_dri2.c | 24 -
src/gallium/drivers/panfrost/pan_context.c | 14 +++-
src/gallium/drivers/panfrost/pan_resource.c | 2 +-
src/gallium/drivers/panfrost/pan_resource.h | 2 ++
5 files changed, 20 insertions(+), 26 deletions(-)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index 4b5583820ed0..4c60d349ddd5 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -521,6 +521,10 @@ struct __DRI2bufferDamageExtensionRec {
* reset the region, followed by a second call with a populated region,
* before a rendering call is made.
*
+* Drivers implementing this entrypoint should take care of resetting the
+* damage region of resources being written to at swapbuffer/flush time.
+* The DRI core will not automate that for you.
+*
* Used to implement EGL_KHR_partial_update.
*
* \param drawable affected drawable
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 526cb1969c18..ea8ae5d44c56 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -1767,7 +1767,6 @@ static EGLBoolean
dri2_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp, _EGLSurface *surf)
{
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
- __DRIdrawable *dri_drawable = dri2_dpy->vtbl->get_dri_drawable(surf);
_EGLContext *ctx = _eglGetCurrentContext();
EGLBoolean ret;
@@ -1775,13 +1774,6 @@ dri2_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp,
_EGLSurface *surf)
dri2_surf_update_fence_fd(ctx, disp, surf);
ret = dri2_dpy->vtbl->swap_buffers(drv, disp, surf);
- /* SwapBuffers marks the end of the frame; reset the damage region for
-* use again next time.
-*/
- if (ret && dri2_dpy->buffer_damage &&
- dri2_dpy->buffer_damage->set_damage_region)
- dri2_dpy->buffer_damage->set_damage_region(dri_drawable, 0, NULL);
-
return ret;
}
@@ -1791,7 +1783,6 @@ dri2_swap_buffers_with_damage(_EGLDriver *drv,
_EGLDisplay *disp,
const EGLint *rects, EGLint n_rects)
{
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
- __DRIdrawable *dri_drawable = dri2_dpy->vtbl->get_dri_drawable(surf);
_EGLContext *ctx = _eglGetCurrentContext();
EGLBoolean ret;
@@ -1800,13 +1791,6 @@ dri2_swap_buffers_with_damage(_EGLDriver *drv,
_EGLDisplay *disp,
ret = dri2_dpy->vtbl->swap_buffers_with_damage(drv, disp, surf,
rects, n_rects);
- /* SwapBuffers marks the end of the frame; reset the damage region for
-* use again next time.
-*/
- if (ret && dri2_dpy->buffer_damage &&
- dri2_dpy->buffer_damage->set_damage_region)
- dri2_dpy->buffer_damage->set_damage_region(dri_drawable, 0, NULL);
-
return ret;
}
@@ -1815,18 +1799,10 @@ dri2_swap_buffers_region(_EGLDriver *drv, _EGLDisplay
*disp, _EGLSurface *surf,
EGLint numRects, const EGLint *rects)
{
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
- __DRIdrawable *dri_drawable = dri2_dpy->vtbl->get_dri_drawable(surf);
EGLBoolean ret;
ret = dri2_dpy->vtbl->swap_buffers_region(drv, disp, surf, numRects, rects);
- /* SwapBuffers marks the end of the frame; reset the damage region for
-* use again next time.
-*/
- if (ret && dri2_dpy->buffer_damage &&
- dri2_dpy->buffer_damage->set_damage_region)
- dri2_dpy->buffer_damage->set_damage_region(dri_drawable, 0, NULL);
-
return ret;
}
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index fa9c92af9f6a..4069ec238fe4 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -1461,7 +1461,8 @@ panfrost_flush(
struct panfrost_job *job = panfrost_get_job_for_fbo(ctx);
/* Nothing to do! */
-if (!job->last_job.gpu && !job->clear) return;
+if (!job->last_job.gpu && !job->clear)
+goto reset_damage;
if (!job->clear && job->last_tiler.gpu)
[Mesa-dev] [PATCH RFC 2/2] dri: Pass a __DRIcontext to ->set_damage_region()
So we can call st_validate_state() from dri2_set_damage_region() in
order to update the BACK_LEFT attachement before using it. If we don't
do that, the resource passed to pipe_screen->set_damage_region() might
be wrong.
Signed-off-by: Boris Brezillon
---
Hi,
I honestly don't know if this is the right thing to do. Passing a
context for somethings that we decided to bind to a surface (and
the underlying resources attached to it) seems wrong, but at the same
time I don't see any other option to sync the gallium drawable state
with the EGL DRI surface one.
Any ideas/suggestions?
Regards,
Boris
---
include/GL/internal/dri_interface.h | 5 +++--
src/egl/drivers/dri2/egl_dri2.c | 7 +--
src/gallium/state_trackers/dri/dri2.c | 11 ++-
3 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index 4c60d349ddd5..e04bed689219 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -527,12 +527,13 @@ struct __DRI2bufferDamageExtensionRec {
*
* Used to implement EGL_KHR_partial_update.
*
+* \param ctx context
* \param drawable affected drawable
* \param nrects number of rectangles provided
* \param rectsthe array of rectangles, lower-left origin
*/
- void (*set_damage_region)(__DRIdrawable *drawable, unsigned int nrects,
- int *rects);
+ void (*set_damage_region)(__DRIcontext *_ctx, __DRIdrawable *drawable,
+ unsigned int nrects, int *rects);
};
/*@}*/
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index ea8ae5d44c56..797a76dab13c 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -1812,11 +1812,14 @@ dri2_set_damage_region(_EGLDriver *drv, _EGLDisplay
*disp, _EGLSurface *surf,
{
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
__DRIdrawable *drawable = dri2_dpy->vtbl->get_dri_drawable(surf);
+ _EGLContext *ctx = _eglGetCurrentContext();
+ __DRIcontext *dri_ctx = ctx ? dri2_egl_context(ctx)->dri_context : NULL;
- if (!dri2_dpy->buffer_damage || !dri2_dpy->buffer_damage->set_damage_region)
+ if (!dri2_dpy->buffer_damage || !dri2_dpy->buffer_damage->set_damage_region
||
+ !dri_ctx)
return EGL_FALSE;
- dri2_dpy->buffer_damage->set_damage_region(drawable, n_rects, rects);
+ dri2_dpy->buffer_damage->set_damage_region(dri_ctx, drawable, n_rects,
rects);
return EGL_TRUE;
}
diff --git a/src/gallium/state_trackers/dri/dri2.c
b/src/gallium/state_trackers/dri/dri2.c
index 11ce19787249..bab503046510 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -36,6 +36,7 @@
#include "util/u_format.h"
#include "util/u_debug.h"
#include "state_tracker/drm_driver.h"
+#include "state_tracker/st_atom.h"
#include "state_tracker/st_cb_bufferobjects.h"
#include "state_tracker/st_cb_fbo.h"
#include "state_tracker/st_cb_texture.h"
@@ -1869,9 +1870,17 @@ static const __DRI2interopExtension dri2InteropExtension
= {
* \brief the DRI2bufferDamageExtension set_damage_region method
*/
static void
-dri2_set_damage_region(__DRIdrawable *dPriv, unsigned int nrects, int *rects)
+dri2_set_damage_region(__DRIcontext *_ctx, __DRIdrawable *dPriv,
+ unsigned int nrects, int *rects)
{
struct dri_drawable *drawable = dri_drawable(dPriv);
+ struct st_context *st = (struct st_context *)dri_context(_ctx)->st;
+
+ /* Make sure drawable->textures[ST_ATTACHMENT_BACK_LEFT] is up-to-date
+* before using it.
+*/
+ st_validate_state(st, ST_PIPELINE_UPDATE_FRAMEBUFFER);
+
struct pipe_resource *resource =
drawable->textures[ST_ATTACHMENT_BACK_LEFT];
struct pipe_screen *screen = resource->screen;
struct pipe_box *boxes = NULL;
--
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
On 29/08/2019 01:12, Dave Airlie wrote:
> On Tue, 27 Aug 2019 at 20:30, 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.
>
> It appears all the results are going to mesa-dev, is there a way to
> send them to the same ppl that would get them from gitlab?
>
> I push to some of my PRs quite a lot (esp when llvm version wrangling).
>
> Dave.
>
That would indeed be the ideal, but I don't know how to do that selectively.
Per https://www.appveyor.com/docs/notifications/ one can use
`{{commitAuthorEmail}}`, but then this would apply to all builds (PRs
and non PRs alike.
It seems the only solution is two have two integrations -- one running
master CC mesa-dev, another running PRs CC'ing the authors. But from
another mail on this thread, perhaps a better solution is to add a
Gitlab Pipeline -> Appveyor trigger, which waits for the result.
I'm afraid I don't have the time right now to dig into this. On one
hand, better integration would be nice, on the other, it might be easier
to wait and see of Appevyor <-> Gitlab gets better by itself upstream.
For now I've disabled PR -> Appveyor builds to keep the noise level down.
Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] egl/android: Enable HAL_PIXEL_FORMAT_RGBA_FP16 format
Reviewed-by: Tapani Pälli
On 8/29/19 12:18 AM, Nataraj Deshpande wrote:
The patch adds support for 64 bit HAL_PIXEL_FORMAT_RGBA_FP16
for android platform.
Fixes android.graphics.cts.BitmapColorSpaceTest#test16bitHardware
which failed in egl due to "Unsupported native buffer format 0x16"
on chromebooks.
Change-Id: I44f886fce27fe5f738d2dc229eed8b59088cf6d6
Signed-off-by: Nataraj Deshpande
---
src/egl/drivers/dri2/platform_android.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/egl/drivers/dri2/platform_android.c
b/src/egl/drivers/dri2/platform_android.c
index 601b29e..97e7947 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -109,6 +109,9 @@ get_format_bpp(int native)
int bpp;
switch (native) {
+ case HAL_PIXEL_FORMAT_RGBA_FP16:
+ bpp = 8;
+ break;
case HAL_PIXEL_FORMAT_RGBA_:
case HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED:
/*
@@ -143,6 +146,7 @@ static int get_fourcc(int native)
* TODO: Remove this once https://issuetracker.google.com/32077885 is
fixed.
*/
case HAL_PIXEL_FORMAT_RGBX_: return __DRI_IMAGE_FOURCC_XBGR;
+ case HAL_PIXEL_FORMAT_RGBA_FP16: return __DRI_IMAGE_FOURCC_ABGR16161616F;
default:
_eglLog(_EGL_WARNING, "unsupported native buffer format 0x%x", native);
}
@@ -161,6 +165,7 @@ static int get_format(int format)
* TODO: Revert this once https://issuetracker.google.com/32077885 is
fixed.
*/
case HAL_PIXEL_FORMAT_RGBX_: return __DRI_IMAGE_FORMAT_XBGR;
+ case HAL_PIXEL_FORMAT_RGBA_FP16: return __DRI_IMAGE_FORMAT_ABGR16161616F;
default:
_eglLog(_EGL_WARNING, "unsupported native buffer format 0x%x", format);
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #151 completed
Build mesa 151 completed Commit 6dc4ddc5f8 by Jan Zielinski on 8/29/2019 9:42 AM: swr/rasterizer: Enable ARB_fragment_layer_viewport 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 #150 failed
Build mesa 150 failed Commit 6e01575b68 by Jan Zielinski on 8/29/2019 9:42 AM: swr/rasterizer: Enable ARB_fragment_layer_viewport Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
