Re: [Mesa-dev] [PATCH 2/3] mesa: fix pbuffers because internally they are front buffers
On Mon, Apr 29, 2019 at 12:28 PM Adam Jackson wrote: > On Fri, 2019-04-26 at 23:31 -0400, Marek Olšák wrote: > > I don't claim to know what this series is trying to fix, but: > > > +* 2) Pbuffers are back buffers from the application point of view, > > +*but they are front buffers from the Mesa point of view, > > +*because they are always single buffered. > > +*/ > > The EGL spec (back to 1.0!) says: > > "The resulting pbuffer will contain color buffers and ancillary buffers > as specified by config." > > This appears to be copied from GLX, which has something more elaborate: > > "The resulting pbuffer will contain color buffers and ancillary buffers > as specified by config. It is possible to create a pbuffer with back > buffers and to swap the front and back buffers by calling > glXSwapBuffers. Note that pbuffers use framebuffer resources so > applications should consider deallocating them when they are not in > use." > > So I'm not convinced that pbuffers are "always single-buffered". The > back buffer is definitely a color buffer, and at least under GLX it > seems like it should be possible to draw red to back, swap, draw blue > to back, glReadBuffer(GL_FRONT), and expect glReadPixels to return red. > Yeah that's possible. The thing is that a GL context can have a doublebuffered config and begin with GL_BACK as the draw buffer, but MakeCurrent can set a pbuffer with a singlebuffered config and then nothing is rendered with Mesa because there is no back buffer. This case appears to work on NVIDIA. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] mesa: rework error handling in glDrawBuffers
I'm adding this hunk, which makes the test pass:
diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
index 1ac0d5d0798..a46599a2872 100644
--- a/src/mesa/main/buffers.c
+++ b/src/mesa/main/buffers.c
@@ -485,7 +485,9 @@ draw_buffers(struct gl_context *ctx, struct
gl_framebuffer *fb, GLsizei n,
} else if (buffers[output] == GL_FRONT ||
buffers[output] == GL_LEFT ||
buffers[output] == GL_RIGHT ||
-buffers[output] == GL_FRONT_AND_BACK) {
+buffers[output] == GL_FRONT_AND_BACK ||
+(buffers[output] == GL_BACK &&
+ _mesa_is_desktop_gl(ctx))) {
_mesa_error(ctx, GL_INVALID_ENUM, "%s(invalid buffer %s)",
caller, _mesa_enum_to_string(buffers[output]));
return;
Marek
On Sat, Apr 27, 2019 at 10:23 AM Mathias Fröhlich
wrote:
> Hi Marek,
>
> one comment/failure inline:
>
> On Saturday, 27 April 2019 05:31:45 CEST Marek Olšák wrote:
> > From: Marek Olšák
> >
> > It's needed by the next pbuffer fix, which changes the behavior of
> > draw_buffer_enum_to_bitmask, so it can't be used to help with error
> > checking.
> > ---
> > src/mesa/main/buffers.c | 53 ++---
> > 1 file changed, 29 insertions(+), 24 deletions(-)
> >
> > diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
> > index d98c015bb24..2148fa1316c 100644
> > --- a/src/mesa/main/buffers.c
> > +++ b/src/mesa/main/buffers.c
> > @@ -430,65 +430,70 @@ draw_buffers(struct gl_context *ctx, struct
> gl_framebuffer *fb, GLsizei n,
> > _mesa_error(ctx, GL_INVALID_OPERATION, "%s(invalid buffers)",
> caller);
> > return;
> >}
> > }
> >
> > supportedMask = supported_buffer_bitmask(ctx, fb);
> > usedBufferMask = 0x0;
> >
> > /* complicated error checking... */
> > for (output = 0; output < n; output++) {
> > - destMask[output] = draw_buffer_enum_to_bitmask(ctx,
> buffers[output]);
> > -
> >if (!no_error) {
> > - /* From the OpenGL 3.0 specification, page 258:
> > - * "Each buffer listed in bufs must be one of the values from
> tables
> > - * 4.5 or 4.6. Otherwise, an INVALID_ENUM error is generated.
> > - */
> > - if (destMask[output] == BAD_MASK) {
> > -_mesa_error(ctx, GL_INVALID_ENUM, "%s(invalid buffer %s)",
> > -caller, _mesa_enum_to_string(buffers[output]));
> > -return;
> > - }
> > -
> > /* From the OpenGL 4.5 specification, page 493 (page 515 of
> the PDF)
> >* "An INVALID_ENUM error is generated if any value in bufs is
> FRONT,
> >* LEFT, RIGHT, or FRONT_AND_BACK . This restriction applies
> to both
> >* the default framebuffer and framebuffer objects, and exists
> because
> >* these constants may themselves refer to multiple buffers,
> as shown
> >* in table 17.4."
> >*
> > - * And on page 492 (page 514 of the PDF):
> > + * From the OpenGL 4.5 specification, page 492 (page 514 of
> the PDF):
> >* "If the default framebuffer is affected, then each of the
> constants
> >* must be one of the values listed in table 17.6 or the
> special value
> >* BACK. When BACK is used, n must be 1 and color values are
> written
> >* into the left buffer for single-buffered contexts, or into
> the back
> >* left buffer for double-buffered contexts."
> >*
> >* Note "special value BACK". GL_BACK also refers to multiple
> buffers,
> >* but it is consider a special case here. This is a change on
> 4.5.
> >* For OpenGL 4.x we check that behaviour. For any previous
> version we
> >* keep considering it wrong (as INVALID_ENUM).
> >*/
> > - if (util_bitcount(destMask[output]) > 1) {
> > -if (_mesa_is_winsys_fbo(fb) && ctx->Version >= 40 &&
> > -buffers[output] == GL_BACK) {
> > - if (n != 1) {
> > - _mesa_error(ctx, GL_INVALID_OPERATION, "%s(with
> GL_BACK n must be 1)",
> > - caller);
> > - return;
> > - }
> > -} else {
> > - _mesa_error(ctx, GL_INVALID_ENUM, "%s(invalid buffer
> %s)",
> > - caller,
> _mesa_enum_to_string(buffers[output]));
> > + if (buffers[output] == GL_BACK &&
> > + _mesa_is_winsys_fbo(fb) &&
> > + _mesa_is_desktop_gl(ctx) &&
> > + ctx->Version >= 40) {
> > +if (n != 1) {
> > + _mesa_error(ctx, GL_INVALID_OPERATION, "%s(with GL_BACK
> n must be 1)",
> > + caller);
> > return;
> > }
> > + } else if (buffers[output] == GL_FRONT ||
> > +
Re: [Mesa-dev] [PATCH 2/5] intel/fs: Lower integer multiply correctly when destination stride equals 4.
Francisco Jerez writes:
> Because the "low" temporary needs to be accessed with word type and
> twice the original stride, attempting to preserve the alignment of the
> original destination can potentially lead to instructions with illegal
> destination stride greater than four. Because the CHV/BXT alignment
> restrictions are now being enforced by the regioning lowering pass run
> after lower_integer_multiplication(), there is no real need to
> preserve the original strides anymore.
>
> Note that this bug can be reproduced on stable branches, but
> back-porting would be non-trivial, because the fix relies on the
> regioning lowering pass recently introduced.
This and PATCH 3 of this series should have landed with a:
Cc: 19.0
The paragraph above recommending against their inclusion in stable
branches was referring to the *then* stable branches when the patch was
written, a couple of weeks before the 19.0 branch point. Unfortunately
the series landed after the branchpoint and patches 2 and 3 missed the
19.0 branch they were intended for. Any chance we could get these into
the next 19.0 stable release?
Thanks to Tapani for realizing the problem!
> ---
> src/intel/compiler/brw_fs.cpp | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
> index f475b617df2..5768e0d6542 100644
> --- a/src/intel/compiler/brw_fs.cpp
> +++ b/src/intel/compiler/brw_fs.cpp
> @@ -3962,13 +3962,11 @@ fs_visitor::lower_integer_multiplication()
> regions_overlap(inst->dst, inst->size_written,
> inst->src[0], inst->size_read(0)) ||
> regions_overlap(inst->dst, inst->size_written,
> -inst->src[1], inst->size_read(1))) {
> +inst->src[1], inst->size_read(1)) ||
> +inst->dst.stride >= 4) {
> needs_mov = true;
> - /* Get a new VGRF but keep the same stride as inst->dst */
> low = fs_reg(VGRF, alloc.allocate(regs_written(inst)),
> inst->dst.type);
> - low.stride = inst->dst.stride;
> - low.offset = inst->dst.offset % REG_SIZE;
> }
>
> /* Get a new VGRF but keep the same stride as inst->dst */
> --
> 2.19.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] intel/compiler: Unset flag reg when FB write is not predicated
In the FS IR we pretend that the instruction is predicated with (+f0.1)
just for flag dependency tracking purposes. Since the instruction
doesn't support predication before Haswell, we unset the predicate so we
should also unset the flag register so that we can round-trip the
disassembly.
---
src/intel/compiler/brw_fs_generator.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/intel/compiler/brw_fs_generator.cpp
b/src/intel/compiler/brw_fs_generator.cpp
index af8350aed6c..84909f83fec 100644
--- a/src/intel/compiler/brw_fs_generator.cpp
+++ b/src/intel/compiler/brw_fs_generator.cpp
@@ -363,6 +363,7 @@ fs_generator::generate_fb_write(fs_inst *inst, struct
brw_reg payload)
{
if (devinfo->gen < 8 && !devinfo->is_haswell) {
brw_set_default_predicate_control(p, BRW_PREDICATE_NONE);
+ brw_set_default_flag_reg(p, 0, 0);
}
const struct brw_reg implied_header =
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Change in Mesa triggers bug in Firefox Nightly with WebRender on old AMD hardware
On Tue, 30 Apr 2019 at 08:42, Ilia Mirkin wrote: > > Thing is, I think that would not be enough - with the "recent" (like > past 2 years) CSO/state change detection changes, I think that you can > end up with no sampler set for a buffer view. Perhaps someone with the > hw can investigate what goes wrong? I'm trying to get a live r600/700 machine, I plugged in my rv635 and rv740 gpus, and they both seemed toast, I've got an rv635 laptop I'll try and get up to date. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Change in Mesa triggers bug in Firefox Nightly with WebRender on old AMD hardware
Thing is, I think that would not be enough - with the "recent" (like
past 2 years) CSO/state change detection changes, I think that you can
end up with no sampler set for a buffer view. Perhaps someone with the
hw can investigate what goes wrong?
On Mon, Apr 29, 2019 at 5:42 PM Marek Olšák wrote:
>
> Reverting the st/mesa commit would be fine.
>
> Marek
>
> On Mon, Apr 29, 2019 at 3:20 PM Ilia Mirkin wrote:
>>
>> On Mon, Apr 29, 2019 at 3:06 PM Viktor Jaegerskuepper
>> wrote:
>> >
>> > Hi Ilia,
>> >
>> > Ilia Mirkin:
>> > > If you can reproduce the issue
>> > > at will, could I recommend you try undoing this hunk:
>> > >
>> > > @@ -1192,7 +1192,6 @@ try_pbo_upload_common(struct gl_context *ctx,
>> > >return false;
>> > >
>> > > cso_save_state(cso, (CSO_BIT_FRAGMENT_SAMPLER_VIEWS |
>> > > -CSO_BIT_FRAGMENT_SAMPLERS |
>> > > CSO_BIT_VERTEX_ELEMENTS |
>> > > CSO_BIT_AUX_VERTEX_BUFFER_SLOT |
>> > > CSO_BIT_FRAMEBUFFER |
>> > >
>> > > and seeing if that helps? Knowing whether it helps, or doesn't help,
>> > > would likely be useful for the investigation.
>> >
>> > It didn't help.
>>
>> OK. That's actually good -- indicates it's not just a straight-up
>> state management bug in the driver.
>>
>> >
>> > > Also, can you check whether the piglit
>> > >
>> > > bin/arb_texture_buffer_object-subdata-sync -fbo -auto
>> > >
>> > > passes or fails both before and after this change?
>> >
>> > It passes both times, i.e. I get:
>> >
>> > PIGLIT: {"result": "pass" }
>> >
>> > Although you didn't write it explicitly, I assumed that I had to build
>> > piglit (and waffle) from source (current git master branch). I have
>> > never compiled or used piglit before, so if my result doesn't make sense
>> > or some information is missing, please tell me because I might have done
>> > a mistake.
>>
>> Sounds like you did it right. This was a piglit that I used to
>> reproduce some issues in nouveau which had to be fixed before this
>> change could be pushed. Sounds like r600 isn't sensitive to precisely
>> the same conditions. There are a bunch of pbo piglits too -- try those
>> out, see if they fail after the change.
>>
>> Marek/Nicolai/Dave - could one of you take a look? As I recall, you
>> guys comprise the current r600 texturing expertise.
>>
>> This change was to remove explicit setting of samplers in the PBO
>> upload path in st/mesa, where it sets up the PBO as a texbuffer and
>> then uses TXF to read from it. In theory, a sampler should not be
>> necessary, and other paths in mesa already don't set one. This path
>> was a left-over from the original PBO upload logic introduced by nha,
>> I believe, where I had requested that it keep setting the samplers
>> anyways, since it would break nouveau otherwise, and I didn't (at the
>> time) know why.
>>
>> A hardware quirk on NVIDIA Tesla and Fermi era GPUs caused the texture
>> lookup mode we used (separate texture view/sampler) to have to have a
>> valid sampler bound at slot 0 no matter what, even though it was not
>> really used (except for an SRGB setting, I believe, which we keep
>> always-on in all samplers). Perhaps the DX10 r600/r700 GPUs had
>> something similar?
>>
>> My fix on nv50 is here: de49e065077fcf26462f1859beafabf5e7a33757.
>>
>> Reverting the change to st/mesa would also be fine -- it's not a big
>> deal -- however there are other ways for these conditions to occur, so
>> it would not be a complete fix for the underlying problem.
>>
>> Cheers,
>>
>> -ilia
>> ___
>> 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] st/dri: decrease input lag by syncing sooner in SwapBuffers
This patch might improve performance, because less submitted unfinished work means less used memory by the unfinished work. Marek On Mon, Apr 29, 2019 at 11:07 AM Michel Dänzer wrote: > On 2019-04-27 6:13 p.m., Rob Clark wrote: > > On Thu, Apr 25, 2019 at 7:06 PM Marek Olšák wrote: > >> > >> From: Marek Olšák > >> > >> It's done by: > >> - decrease the number of frames in flight by 1 > >> - flush before throttling in SwapBuffers > >> (instead of wait-then-flush, do flush-then-wait) > >> > >> The improvement is apparent with Unigine Heaven. > >> > >> Previously: > >> draw frame 2 > >> wait frame 0 > >> flush frame 2 > >> present frame 2 > >> > >> The input lag is 2 frames. > >> > >> Now: > >> draw frame 2 > >> flush frame 2 > >> wait frame 1 > >> present frame 2 > >> > >> The input lag is 1 frame. Flushing is done before waiting, because > >> otherwise the device would be idle after waiting. > >> > >> Nine is affected because it also uses the pipe cap. > >> --- > >> src/gallium/auxiliary/util/u_screen.c | 2 +- > >> src/gallium/state_trackers/dri/dri_drawable.c | 20 +-- > >> 2 files changed, 11 insertions(+), 11 deletions(-) > >> > >> diff --git a/src/gallium/auxiliary/util/u_screen.c > b/src/gallium/auxiliary/util/u_screen.c > >> index 27f51e0898e..410f17421e6 100644 > >> --- a/src/gallium/auxiliary/util/u_screen.c > >> +++ b/src/gallium/auxiliary/util/u_screen.c > >> @@ -349,21 +349,21 @@ u_pipe_screen_get_param_defaults(struct > pipe_screen *pscreen, > >> case PIPE_CAP_MAX_VARYINGS: > >>return 8; > >> > >> case PIPE_CAP_COMPUTE_GRID_INFO_LAST_BLOCK: > >>return 0; > >> > >> case PIPE_CAP_COMPUTE_SHADER_DERIVATIVES: > >>return 0; > >> > >> case PIPE_CAP_MAX_FRAMES_IN_FLIGHT: > >> - return 2; > >> + return 1; > > > > would it be safer to leave the current default and let drivers opt-in > > to the lower # individually? I guess triple buffering would still be > > better for some of the smaller gpu's? > > This patch doesn't prevent triple buffering. The application can still > prepare up to one frame worth of GPU commands before the GPU has > finished processing the commands of the previous frame (while the > pre-previous frame is being displayed). > > I just think the term "in flight" should maybe be defined a bit better, > but it's not a blocker and could be done in a follow-up patch. > > > -- > Earthling Michel Dänzer | https://www.amd.com > Libre software enthusiast | Mesa and X developer > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110552] Land Gallium nine fixes for 19.1
https://bugs.freedesktop.org/show_bug.cgi?id=110552 Axel Davy changed: What|Removed |Added Blocks||110439 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=110439 [Bug 110439] [TRACKER] Mesa 19.1 feature tracker -- 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 110439] [TRACKER] Mesa 19.1 feature tracker
https://bugs.freedesktop.org/show_bug.cgi?id=110439 Axel Davy changed: What|Removed |Added Depends on||110552 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=110552 [Bug 110552] Land Gallium nine fixes for 19.1 -- 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 110552] Land Gallium nine fixes for 19.1
https://bugs.freedesktop.org/show_bug.cgi?id=110552 Bug ID: 110552 Summary: Land Gallium nine fixes for 19.1 Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Gallium/StateTracker/galliumnine Assignee: mesa-dev@lists.freedesktop.org Reporter: davyax...@gmail.com QA Contact: mesa-dev@lists.freedesktop.org https://gitlab.freedesktop.org/mesa/mesa/merge_requests/748 -- 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 2/2] egl: add EGL_platform_device support
On Mon, Apr 29, 2019 at 4:00 AM Pekka Paalanen wrote: > On Sat, 27 Apr 2019 09:38:27 -0400 > Marek Olšák wrote: > > > Those are all valid reasons, but I don't wanna expose swrast for AMD's > > customers. > > Hi Marek, > > is you objection that you will never want to see any software renderer > in the list, or that you don't want to see a software renderer only as > long as it doesn't actually work? > > Why do you not "wanna expose swrast for AMD's customers"? > > Are you talking about swrast specifically or all the software renderers > in Mesa? > > I'm not an AMD customer if you mean someone paying for support rather > than just buying their hardware, so I cannot speak for them. However, I > would be very happy to have a software renderer available to be picked > the same way as any other hardware renderer, so that I can use it in > graphical test suites (a point from Anholt) testing also the EGL glue > in addition to the pixels produced. > > The thing will be run on boxes with AMD GPUs, and in those cases there > must be a way to *not* use the AMD GPU, and use the software renderer > instead when wanted. Not by environment variables or anything hacky > like that, but by deliberately choosing the software renderer in the > program. It will need an EGLSurface too. > > How would this be made to work in the future? > A software renderer could be exposed by adding a new EGL function on top of EGL_EXT_device_base, for example: // EGL_MESA_device_software EGLBoolean eglQuerySoftwareDeviceMESA(EGLDeviceEXT *swdevice); You would get the swrast device from that function instead of eglQueryDevicesEXT. It clearly separates hw and sw devices but keeps everything else the same. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Change in Mesa triggers bug in Firefox Nightly with WebRender on old AMD hardware
Reverting the st/mesa commit would be fine.
Marek
On Mon, Apr 29, 2019 at 3:20 PM Ilia Mirkin wrote:
> On Mon, Apr 29, 2019 at 3:06 PM Viktor Jaegerskuepper
> wrote:
> >
> > Hi Ilia,
> >
> > Ilia Mirkin:
> > > If you can reproduce the issue
> > > at will, could I recommend you try undoing this hunk:
> > >
> > > @@ -1192,7 +1192,6 @@ try_pbo_upload_common(struct gl_context *ctx,
> > >return false;
> > >
> > > cso_save_state(cso, (CSO_BIT_FRAGMENT_SAMPLER_VIEWS |
> > > -CSO_BIT_FRAGMENT_SAMPLERS |
> > > CSO_BIT_VERTEX_ELEMENTS |
> > > CSO_BIT_AUX_VERTEX_BUFFER_SLOT |
> > > CSO_BIT_FRAMEBUFFER |
> > >
> > > and seeing if that helps? Knowing whether it helps, or doesn't help,
> > > would likely be useful for the investigation.
> >
> > It didn't help.
>
> OK. That's actually good -- indicates it's not just a straight-up
> state management bug in the driver.
>
> >
> > > Also, can you check whether the piglit
> > >
> > > bin/arb_texture_buffer_object-subdata-sync -fbo -auto
> > >
> > > passes or fails both before and after this change?
> >
> > It passes both times, i.e. I get:
> >
> > PIGLIT: {"result": "pass" }
> >
> > Although you didn't write it explicitly, I assumed that I had to build
> > piglit (and waffle) from source (current git master branch). I have
> > never compiled or used piglit before, so if my result doesn't make sense
> > or some information is missing, please tell me because I might have done
> > a mistake.
>
> Sounds like you did it right. This was a piglit that I used to
> reproduce some issues in nouveau which had to be fixed before this
> change could be pushed. Sounds like r600 isn't sensitive to precisely
> the same conditions. There are a bunch of pbo piglits too -- try those
> out, see if they fail after the change.
>
> Marek/Nicolai/Dave - could one of you take a look? As I recall, you
> guys comprise the current r600 texturing expertise.
>
> This change was to remove explicit setting of samplers in the PBO
> upload path in st/mesa, where it sets up the PBO as a texbuffer and
> then uses TXF to read from it. In theory, a sampler should not be
> necessary, and other paths in mesa already don't set one. This path
> was a left-over from the original PBO upload logic introduced by nha,
> I believe, where I had requested that it keep setting the samplers
> anyways, since it would break nouveau otherwise, and I didn't (at the
> time) know why.
>
> A hardware quirk on NVIDIA Tesla and Fermi era GPUs caused the texture
> lookup mode we used (separate texture view/sampler) to have to have a
> valid sampler bound at slot 0 no matter what, even though it was not
> really used (except for an SRGB setting, I believe, which we keep
> always-on in all samplers). Perhaps the DX10 r600/r700 GPUs had
> something similar?
>
> My fix on nv50 is here: de49e065077fcf26462f1859beafabf5e7a33757.
>
> Reverting the change to st/mesa would also be fine -- it's not a big
> deal -- however there are other ways for these conditions to occur, so
> it would not be a complete fix for the underlying problem.
>
> Cheers,
>
> -ilia
> ___
> 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] Change in Mesa triggers bug in Firefox Nightly with WebRender on old AMD hardware
Hi Ilia,
Ilia Mirkin:
> If you can reproduce the issue
> at will, could I recommend you try undoing this hunk:
>
> @@ -1192,7 +1192,6 @@ try_pbo_upload_common(struct gl_context *ctx,
>return false;
>
> cso_save_state(cso, (CSO_BIT_FRAGMENT_SAMPLER_VIEWS |
> -CSO_BIT_FRAGMENT_SAMPLERS |
> CSO_BIT_VERTEX_ELEMENTS |
> CSO_BIT_AUX_VERTEX_BUFFER_SLOT |
> CSO_BIT_FRAMEBUFFER |
>
> and seeing if that helps? Knowing whether it helps, or doesn't help,
> would likely be useful for the investigation.
It didn't help.
> Also, can you check whether the piglit
>
> bin/arb_texture_buffer_object-subdata-sync -fbo -auto
>
> passes or fails both before and after this change?
It passes both times, i.e. I get:
PIGLIT: {"result": "pass" }
Although you didn't write it explicitly, I assumed that I had to build
piglit (and waffle) from source (current git master branch). I have
never compiled or used piglit before, so if my result doesn't make sense
or some information is missing, please tell me because I might have done
a mistake.
Thanks,
Viktor
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Change in Mesa triggers bug in Firefox Nightly with WebRender on old AMD hardware
On Mon, Apr 29, 2019 at 3:06 PM Viktor Jaegerskuepper
wrote:
>
> Hi Ilia,
>
> Ilia Mirkin:
> > If you can reproduce the issue
> > at will, could I recommend you try undoing this hunk:
> >
> > @@ -1192,7 +1192,6 @@ try_pbo_upload_common(struct gl_context *ctx,
> >return false;
> >
> > cso_save_state(cso, (CSO_BIT_FRAGMENT_SAMPLER_VIEWS |
> > -CSO_BIT_FRAGMENT_SAMPLERS |
> > CSO_BIT_VERTEX_ELEMENTS |
> > CSO_BIT_AUX_VERTEX_BUFFER_SLOT |
> > CSO_BIT_FRAMEBUFFER |
> >
> > and seeing if that helps? Knowing whether it helps, or doesn't help,
> > would likely be useful for the investigation.
>
> It didn't help.
OK. That's actually good -- indicates it's not just a straight-up
state management bug in the driver.
>
> > Also, can you check whether the piglit
> >
> > bin/arb_texture_buffer_object-subdata-sync -fbo -auto
> >
> > passes or fails both before and after this change?
>
> It passes both times, i.e. I get:
>
> PIGLIT: {"result": "pass" }
>
> Although you didn't write it explicitly, I assumed that I had to build
> piglit (and waffle) from source (current git master branch). I have
> never compiled or used piglit before, so if my result doesn't make sense
> or some information is missing, please tell me because I might have done
> a mistake.
Sounds like you did it right. This was a piglit that I used to
reproduce some issues in nouveau which had to be fixed before this
change could be pushed. Sounds like r600 isn't sensitive to precisely
the same conditions. There are a bunch of pbo piglits too -- try those
out, see if they fail after the change.
Marek/Nicolai/Dave - could one of you take a look? As I recall, you
guys comprise the current r600 texturing expertise.
This change was to remove explicit setting of samplers in the PBO
upload path in st/mesa, where it sets up the PBO as a texbuffer and
then uses TXF to read from it. In theory, a sampler should not be
necessary, and other paths in mesa already don't set one. This path
was a left-over from the original PBO upload logic introduced by nha,
I believe, where I had requested that it keep setting the samplers
anyways, since it would break nouveau otherwise, and I didn't (at the
time) know why.
A hardware quirk on NVIDIA Tesla and Fermi era GPUs caused the texture
lookup mode we used (separate texture view/sampler) to have to have a
valid sampler bound at slot 0 no matter what, even though it was not
really used (except for an SRGB setting, I believe, which we keep
always-on in all samplers). Perhaps the DX10 r600/r700 GPUs had
something similar?
My fix on nv50 is here: de49e065077fcf26462f1859beafabf5e7a33757.
Reverting the change to st/mesa would also be fine -- it's not a big
deal -- however there are other ways for these conditions to occur, so
it would not be a complete fix for the underlying problem.
Cheers,
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110439] [TRACKER] Mesa 19.1 feature tracker
https://bugs.freedesktop.org/show_bug.cgi?id=110439 Plamena Manolova changed: What|Removed |Added Depends on||110551 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=110551 [Bug 110551] Land patches for re-enabling fast color clears for GEN11 -- 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 109599] small shadows are not drawn in various games (shadow map bias issue?)
https://bugs.freedesktop.org/show_bug.cgi?id=109599 --- Comment #24 from tempel.jul...@gmail.com --- Created attachment 144115 --> https://bugs.freedesktop.org/attachment.cgi?id=144115=edit hitman 2 renderdoc capture 6/6 -- 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 109599] small shadows are not drawn in various games (shadow map bias issue?)
https://bugs.freedesktop.org/show_bug.cgi?id=109599 --- Comment #25 from tempel.jul...@gmail.com --- Upload complete. -- 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 109599] small shadows are not drawn in various games (shadow map bias issue?)
https://bugs.freedesktop.org/show_bug.cgi?id=109599 --- Comment #23 from tempel.jul...@gmail.com --- Created attachment 144114 --> https://bugs.freedesktop.org/attachment.cgi?id=144114=edit hitman 2 renderdoc capture 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 109599] small shadows are not drawn in various games (shadow map bias issue?)
https://bugs.freedesktop.org/show_bug.cgi?id=109599 --- Comment #22 from tempel.jul...@gmail.com --- Created attachment 144113 --> https://bugs.freedesktop.org/attachment.cgi?id=144113=edit hitman 2 renderdoc capture 4 -- 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 109599] small shadows are not drawn in various games (shadow map bias issue?)
https://bugs.freedesktop.org/show_bug.cgi?id=109599 --- Comment #21 from tempel.jul...@gmail.com --- Created attachment 144112 --> https://bugs.freedesktop.org/attachment.cgi?id=144112=edit hitman 2 renderdoc capture 3 -- 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 109599] small shadows are not drawn in various games (shadow map bias issue?)
https://bugs.freedesktop.org/show_bug.cgi?id=109599 --- Comment #20 from tempel.jul...@gmail.com --- Created attachment 144111 --> https://bugs.freedesktop.org/attachment.cgi?id=144111=edit hitman 2 renderdoc capture 2 -- 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 109599] small shadows are not drawn in various games (shadow map bias issue?)
https://bugs.freedesktop.org/show_bug.cgi?id=109599 --- Comment #19 from tempel.jul...@gmail.com --- Created attachment 144110 --> https://bugs.freedesktop.org/attachment.cgi?id=144110=edit hitman 2 renderdoc capture 1 -- 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 1/2] radeonsi: use new atomic LLVM helpers
The patch this depends on, "ac,ac/nir: use a better sync scope for
shared atomics", has been pushed:
https://gitlab.freedesktop.org/mesa/mesa/commit/bd4c661ad08e772fdccb562ffbb2f45705c4fec8
On Fri, 26 Apr 2019 at 21:41, Marek Olšák wrote:
>
> From: Marek Olšák
>
> This depends on "ac,ac/nir: use a better sync scope for shared atomics"
> ---
> src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
> b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
> index eb90bfb10ff..5e540fc5098 100644
> --- a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
> +++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
> @@ -776,38 +776,36 @@ static void store_emit(
> emit_data->output[emit_data->chan] =
> ac_build_image_opcode(>ac, );
> }
> }
>
> static void atomic_emit_memory(struct si_shader_context *ctx,
> struct lp_build_emit_data *emit_data) {
> LLVMBuilderRef builder = ctx->ac.builder;
> const struct tgsi_full_instruction * inst = emit_data->inst;
> LLVMValueRef ptr, result, arg;
> + const char *sync_scope = HAVE_LLVM >= 0x0900 ? "workgroup-one-as" :
> "workgroup";
>
> ptr = get_memory_ptr(ctx, inst, ctx->i32, 1);
>
> arg = lp_build_emit_fetch(>bld_base, inst, 2, 0);
> arg = ac_to_integer(>ac, arg);
>
> if (inst->Instruction.Opcode == TGSI_OPCODE_ATOMCAS) {
> LLVMValueRef new_data;
> new_data = lp_build_emit_fetch(>bld_base,
>inst, 3, 0);
>
> new_data = ac_to_integer(>ac, new_data);
>
> - result = LLVMBuildAtomicCmpXchg(builder, ptr, arg, new_data,
> -
> LLVMAtomicOrderingSequentiallyConsistent,
> -
> LLVMAtomicOrderingSequentiallyConsistent,
> - false);
> -
> + result = ac_build_atomic_cmp_xchg(>ac, ptr, arg,
> new_data,
> + sync_scope);
> result = LLVMBuildExtractValue(builder, result, 0, "");
> } else {
> LLVMAtomicRMWBinOp op;
>
> switch(inst->Instruction.Opcode) {
> case TGSI_OPCODE_ATOMUADD:
> op = LLVMAtomicRMWBinOpAdd;
> break;
> case TGSI_OPCODE_ATOMXCHG:
> op = LLVMAtomicRMWBinOpXchg;
> @@ -830,23 +828,21 @@ static void atomic_emit_memory(struct si_shader_context
> *ctx,
> case TGSI_OPCODE_ATOMIMIN:
> op = LLVMAtomicRMWBinOpMin;
> break;
> case TGSI_OPCODE_ATOMIMAX:
> op = LLVMAtomicRMWBinOpMax;
> break;
> default:
> unreachable("unknown atomic opcode");
> }
>
> - result = LLVMBuildAtomicRMW(builder, op, ptr, arg,
> -
> LLVMAtomicOrderingSequentiallyConsistent,
> - false);
> + result = ac_build_atomic_rmw(>ac, op, ptr, arg,
> sync_scope);
> }
> emit_data->output[emit_data->chan] =
> LLVMBuildBitCast(builder, result, ctx->f32, "");
> }
>
> static void atomic_emit(
> const struct lp_build_tgsi_action *action,
> struct lp_build_tgsi_context *bld_base,
> struct lp_build_emit_data *emit_data)
> {
> --
> 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] [Bug 109599] small shadows are not drawn in various games (shadow map bias issue?)
https://bugs.freedesktop.org/show_bug.cgi?id=109599 --- Comment #18 from tempel.jul...@gmail.com --- Compressing and uploading the capture is on its way. Here are current screenshots showing the issue with latest mesa-git. When you switch between the images, you can clearly see some shadows missing with radv vs. amdvlk at the fence and at the trees in the background. This is completely reproducible, such as the issue in HotS. https://abload.de/img/amdvlk86jjt.png https://abload.de/img/radvikk6c.png -- 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 2/3] mesa: fix pbuffers because internally they are front buffers
On Fri, 2019-04-26 at 23:31 -0400, Marek Olšák wrote: I don't claim to know what this series is trying to fix, but: > +* 2) Pbuffers are back buffers from the application point of view, > +*but they are front buffers from the Mesa point of view, > +*because they are always single buffered. > +*/ The EGL spec (back to 1.0!) says: "The resulting pbuffer will contain color buffers and ancillary buffers as specified by config." This appears to be copied from GLX, which has something more elaborate: "The resulting pbuffer will contain color buffers and ancillary buffers as specified by config. It is possible to create a pbuffer with back buffers and to swap the front and back buffers by calling glXSwapBuffers. Note that pbuffers use framebuffer resources so applications should consider deallocating them when they are not in use." So I'm not convinced that pbuffers are "always single-buffered". The back buffer is definitely a color buffer, and at least under GLX it seems like it should be possible to draw red to back, swap, draw blue to back, glReadBuffer(GL_FRONT), and expect glReadPixels to return red. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/3] Pbuffer fixes
On 2019-04-27 5:31 a.m., Marek Olšák wrote: > Hi, > > This series fixes pbuffers for EGL as exercised by the egl_ext_device- > _base piglit test. > > It passes piglit, GL-CTS, dEQP, and The Hitchhiker's Guide to the Galaxy, > but I didn't test GLX, so things might still break horribly there. I trust you won't push this without testing GLX first then. :) -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109599] small shadows are not drawn in various games (shadow map bias issue?)
https://bugs.freedesktop.org/show_bug.cgi?id=109599 --- Comment #17 from Samuel Pitoiset --- Yes, please attach a new trace. -- 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] st/dri: decrease input lag by syncing sooner in SwapBuffers
On 2019-04-27 6:13 p.m., Rob Clark wrote: > On Thu, Apr 25, 2019 at 7:06 PM Marek Olšák wrote: >> >> From: Marek Olšák >> >> It's done by: >> - decrease the number of frames in flight by 1 >> - flush before throttling in SwapBuffers >> (instead of wait-then-flush, do flush-then-wait) >> >> The improvement is apparent with Unigine Heaven. >> >> Previously: >> draw frame 2 >> wait frame 0 >> flush frame 2 >> present frame 2 >> >> The input lag is 2 frames. >> >> Now: >> draw frame 2 >> flush frame 2 >> wait frame 1 >> present frame 2 >> >> The input lag is 1 frame. Flushing is done before waiting, because >> otherwise the device would be idle after waiting. >> >> Nine is affected because it also uses the pipe cap. >> --- >> src/gallium/auxiliary/util/u_screen.c | 2 +- >> src/gallium/state_trackers/dri/dri_drawable.c | 20 +-- >> 2 files changed, 11 insertions(+), 11 deletions(-) >> >> diff --git a/src/gallium/auxiliary/util/u_screen.c >> b/src/gallium/auxiliary/util/u_screen.c >> index 27f51e0898e..410f17421e6 100644 >> --- a/src/gallium/auxiliary/util/u_screen.c >> +++ b/src/gallium/auxiliary/util/u_screen.c >> @@ -349,21 +349,21 @@ u_pipe_screen_get_param_defaults(struct pipe_screen >> *pscreen, >> case PIPE_CAP_MAX_VARYINGS: >>return 8; >> >> case PIPE_CAP_COMPUTE_GRID_INFO_LAST_BLOCK: >>return 0; >> >> case PIPE_CAP_COMPUTE_SHADER_DERIVATIVES: >>return 0; >> >> case PIPE_CAP_MAX_FRAMES_IN_FLIGHT: >> - return 2; >> + return 1; > > would it be safer to leave the current default and let drivers opt-in > to the lower # individually? I guess triple buffering would still be > better for some of the smaller gpu's? This patch doesn't prevent triple buffering. The application can still prepare up to one frame worth of GPU commands before the GPU has finished processing the commands of the previous frame (while the pre-previous frame is being displayed). I just think the term "in flight" should maybe be defined a bit better, but it's not a blocker and could be done in a follow-up patch. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] panfrosti/ci: Initial commit
> A typical run takes around 20 mins and the time spent besides running the > tests themselves is a small part. Oh, nice! That's a lot quicker than I expected :) > Well, this is information about the code, so I think it makes sense to store > it alongside it. It really needs to be kept in sync so we can know what code > changes broke the expectations. > > But as Eric mentioned, we should probably store only failures, which will > (hopefully :)) reduce with time. There you go, then :) > Well, a diff will be produced after a failed run. One should be able to just > add that diff to the commit that fixed stuff and submit that for code > review. ...Sounds automated to me! :) > Will checkout a release tag as per Eric's comment. +1 > It's only once every 5k tests, so it may not be that bad :) Sure :P ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] panfrosti/ci: Initial commit
+1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 109599] small shadows are not drawn in various games (shadow map bias issue?)
https://bugs.freedesktop.org/show_bug.cgi?id=109599 tempel.jul...@gmail.com changed: What|Removed |Added Summary|small shadows are not drawn |small shadows are not drawn |in Heroes of the Storm |in various games (shadow ||map bias issue?) -- 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 109599] small shadows are not drawn in various games (shadow map bias issue?)
https://bugs.freedesktop.org/show_bug.cgi?id=109599 --- Comment #16 from tempel.jul...@gmail.com --- I changed the ticket title accordingly. Would a renderdoc capture for Hitman be desirable? If you're really mean (which I'm of course not, issue is hardly noticeable) you could say that radv doesn't render lots of games correctly, so would an update regarding the matter be possible? ;) -- 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] Mesa 3D
On Fri, 26 Apr 2019 at 08:13, Rain_Kuper wrote: > > Hello,does Mesa 3D have support for NVIDIA Tegra K1 SoC and Android? > Tegra K1 should work with the nouveau kernel and mesa drivers. Android is also amongst the platforms where Mesa runs. IIRC since Android makes heavy use of MT, you might need to rebase/apply these [1] nouveau patches. That said, best thing is to try if yourself - yet YMMV. I would start with Android-x86. HTH Emil [1] https://patchwork.freedesktop.org/series/53595/ Note: there might be a newer revision, haven't checked. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110525] [CTS] dEQP-VK.api.invariance.random crashes
https://bugs.freedesktop.org/show_bug.cgi?id=110525 --- Comment #3 from Bas Nieuwenhuizen --- Yep mesa-build is my debug build. (Also note that I spelled the env var wrong in the pasted text. I did rerun it with the correct env var which did not result in any changes.) -- 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 0/3] Pbuffer fixes
On Sat, 27 Apr 2019 at 04:31, Marek Olšák wrote: > > Hi, > > This series fixes pbuffers for EGL as exercised by the egl_ext_device- > _base piglit test. > > It passes piglit, GL-CTS, dEQP, and The Hitchhiker's Guide to the Galaxy, > but I didn't test GLX, so things might still break horribly there. > > Rbs welcome, > Thanks for sorting these our Marek. With Mathias' comment addressed the series is: Reviewed-by: Emil Velikov Can I ask you to run these against the QT test suite - it did high-light a large number of issues in the past. Please let Adam and others have a look before merging these. Thanks -Emil Note to self: nominate these for stable, if we don't have any regressions after a few weeks. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3] radv: fix set_output_usage_mask() with composite and 64-bit types
Reviewed-by: Samuel Pitoiset
On 4/27/19 11:47 AM, Rhys Perry wrote:
It previously used var->type instead of deref_instr->type and didn't
handle 64-bit outputs.
This fixes lots of transform feedback CTS tests involving transform
feedback and geometry shaders (mostly
dEQP-VK.transform_feedback.fuzz.random_geometry.*)
v2: fix writemask widening when comp != 0
v3: fix 64-bit variables when comp != 0, again
Signed-off-by: Rhys Perry
Cc: 19.0
---
src/amd/vulkan/radv_shader_info.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/src/amd/vulkan/radv_shader_info.c
b/src/amd/vulkan/radv_shader_info.c
index 932a1852266..e771ad79878 100644
--- a/src/amd/vulkan/radv_shader_info.c
+++ b/src/amd/vulkan/radv_shader_info.c
@@ -112,6 +112,15 @@ gather_intrinsic_load_deref_info(const nir_shader *nir,
}
}
+static uint32_t
+widen_writemask(uint32_t wrmask)
+{
+ uint32_t new_wrmask = 0;
+ for(unsigned i = 0; i < 4; i++)
+ new_wrmask |= (wrmask & (1 << i) ? 0x3 : 0x0) << (i * 2);
+ return new_wrmask;
+}
+
static void
set_output_usage_mask(const nir_shader *nir, const nir_intrinsic_instr *instr,
uint8_t *output_usage_mask)
@@ -119,7 +128,7 @@ set_output_usage_mask(const nir_shader *nir, const
nir_intrinsic_instr *instr,
nir_deref_instr *deref_instr =
nir_instr_as_deref(instr->src[0].ssa->parent_instr);
nir_variable *var = nir_deref_instr_get_variable(deref_instr);
- unsigned attrib_count = glsl_count_attribute_slots(var->type, false);
+ unsigned attrib_count = glsl_count_attribute_slots(deref_instr->type,
false);
unsigned idx = var->data.location;
unsigned comp = var->data.location_frac;
unsigned const_offset = 0;
@@ -127,15 +136,19 @@ set_output_usage_mask(const nir_shader *nir, const
nir_intrinsic_instr *instr,
get_deref_offset(deref_instr, _offset);
if (var->data.compact) {
+ assert(!glsl_type_is_64bit(deref_instr->type));
const_offset += comp;
output_usage_mask[idx + const_offset / 4] |= 1 << (const_offset
% 4);
return;
}
- for (unsigned i = 0; i < attrib_count; i++) {
+ uint32_t wrmask = nir_intrinsic_write_mask(instr);
+ if (glsl_type_is_64bit(deref_instr->type))
+ wrmask = widen_writemask(wrmask);
+
+ for (unsigned i = 0; i < attrib_count; i++)
output_usage_mask[idx + i + const_offset] |=
- instr->const_index[0] << comp;
- }
+ ((wrmask >> (i * 4)) & 0xf) << comp;
}
static void
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110525] [CTS] dEQP-VK.api.invariance.random crashes
https://bugs.freedesktop.org/show_bug.cgi?id=110525 --- Comment #2 from Samuel Pitoiset --- Uhu? I can definitely reproduce it. Do you have assertions enabled in your build? -- 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] panfrosti/ci: Initial commit
On 4/26/19 9:14 PM, Eric Anholt wrote: Alyssa Rosenzweig writes: We start by building a container in Docker that contains a suitable rootfs and kernel for the DUT, deqp and all dependencies for building Mesa itself. Out of curiosity, what's the performance impact of this? If there are no changes to the kernel or to deqp (but mesa had a commit somewhere in Panfrost space), do we have to rebuild the former two? Does ccache maybe pick that up? I'm trying to get a sense for how long it takes between pushing a commit and getting a CI answer, and maybe if that can be shortened. the expectations that are stored in git. Might it be better to track this outside so we don't pollute mesa with changes to that largely autogenerated file? Or I guess that's problematic since then we lose branch information / etc. Hopefully just current expected fails get stored in git. Actually, passes were being stored as well :) Thanks for the idea! Is there an automated way to do this based on the results of LAVA/CI? + git clone --depth 1 https://github.com/KhronosGroup/VK-GL-CTS.git . && \ Is this the right repo? I recall getting deqp source from Google's servers (Chromium git). I suppose it's the same. VK-GL-CTS is the official conformance suite, and it includes dEQP. You need to use a release tag, or you'll have extra garbage tests expecting nonstandardized behavior being run. Same for dEQP master. Done. Thanks, Tomeu ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support
On Sat, 27 Apr 2019 09:38:27 -0400 Marek Olšák wrote: > Those are all valid reasons, but I don't wanna expose swrast for AMD's > customers. Hi Marek, is you objection that you will never want to see any software renderer in the list, or that you don't want to see a software renderer only as long as it doesn't actually work? Why do you not "wanna expose swrast for AMD's customers"? Are you talking about swrast specifically or all the software renderers in Mesa? I'm not an AMD customer if you mean someone paying for support rather than just buying their hardware, so I cannot speak for them. However, I would be very happy to have a software renderer available to be picked the same way as any other hardware renderer, so that I can use it in graphical test suites (a point from Anholt) testing also the EGL glue in addition to the pixels produced. The thing will be run on boxes with AMD GPUs, and in those cases there must be a way to *not* use the AMD GPU, and use the software renderer instead when wanted. Not by environment variables or anything hacky like that, but by deliberately choosing the software renderer in the program. It will need an EGLSurface too. How would this be made to work in the future? Thanks, pq > > Marek > > On Sat, Apr 27, 2019, 5:45 AM Mathias Fröhlich > wrote: > > > Hi Marek, > > > > On Wednesday, 24 April 2019 02:01:42 CEST Marek Olšák wrote: > > > Adam, did you notice my original suggestion "If there is at least 1 drm > > > device, swrast won't be in the list."? which means swrast would be in the > > > list for your "dumb" GPUs. > > > > Imagine a box with a low end drm capable hardware chip like you find > > sometimes > > in server type boxes (intel/matrox...). Otherwise the box is equipped with > > lots of cpu > > power. This is something that you will find a lot in that major > > engineering application > > environment. Your application will be glad to find the swrast renderer > > that is finally > > more capable than the 'GPU' mostly there to drive an administration > > console. > > You do not want to lock a swrast 'device' (or however you want to call it) > > out by > > a may be less capable 'console GPU'. > > > > Beside that having a second type of 'normalized renderer' like Eric was > > telling > > about is an other one. > > > > As well as sometimes it may make sense to utilize the GPU > > with one set of work and a second GPU with an other set of work in > > parallel. > > When you only find a single gpu device in one box, you may be glad to find > > a swrast device that you can make use of in parallel with the gpu without > > the need > > to put up different code paths in your application. > > > > May be I can come up with other cases, but thats the 5 minutes for now ... > > > > best > > > > Mathias > > > > > > pgpYCtED5brQZ.pgp Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] panfrosti/ci: Initial commit
On 4/26/19 6:24 PM, Alyssa Rosenzweig wrote: We start by building a container in Docker that contains a suitable rootfs and kernel for the DUT, deqp and all dependencies for building Mesa itself. Out of curiosity, what's the performance impact of this? If there are no changes to the kernel or to deqp (but mesa had a commit somewhere in Panfrost space), do we have to rebuild the former two? Does ccache maybe pick that up? I'm trying to get a sense for how long it takes between pushing a commit and getting a CI answer, and maybe if that can be shortened. A typical run takes around 20 mins and the time spent besides running the tests themselves is a small part. https://gitlab.freedesktop.org/tomeu/mesa/pipelines/33402 We use Docker to cache as much as possible, and then use ccache when building Mesa. Depending on which runner is assigned, we may find a useful ccache dir, or not. the expectations that are stored in git. Might it be better to track this outside so we don't pollute mesa with changes to that largely autogenerated file? Or I guess that's problematic since then we lose branch information / etc. Well, this is information about the code, so I think it makes sense to store it alongside it. It really needs to be kept in sync so we can know what code changes broke the expectations. But as Eric mentioned, we should probably store only failures, which will (hopefully :)) reduce with time. Any code that changes the expectations (hopefully tests are fixed) needs to also update the expectations file. Is there an automated way to do this based on the results of LAVA/CI? Well, a diff will be produced after a failed run. One should be able to just add that diff to the commit that fixed stuff and submit that for code review. + git clone --depth 1 https://github.com/KhronosGroup/VK-GL-CTS.git . && \ Is this the right repo? I recall getting deqp source from Google's servers (Chromium git). I suppose it's the same. Will checkout a release tag as per Eric's comment. + git clone --depth 1 https://gitlab.freedesktop.org/tomeu/mesa.git -b panfrost-ci . && \ U Oops :) +# To prevent memory leaks from slowing throughput, restart everything between batches *blush* It's only once every 5k tests, so it may not be that bad :) Thanks, Tomeu ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
