Re: [Mesa-dev] [PATCH 3/3] docs/releasing: Add note about using a staging branch
For the first two patches in the series: Reviewed-by: Juan A. Suarez For the 3rd patch, I'm fine with the proposal, but I would like to know the feedback from others. In my case, for instance, I'm already using a staging branch, but in a completely different repository (on GitHub), as our CI integrates better here than with the freedesktop repository, and I have more freedom to add/remove/squash/reorder commits as I need in the branch. But as I said, I'm fine with pushing those changes also to the staging branch in the freedesktop repository (does it allow to force push?). J.A. On Mon, 2018-05-21 at 10:34 -0700, Dylan Baker wrote: > --- > docs/releasing.html | 19 +++ > 1 file changed, 19 insertions(+) > > diff --git a/docs/releasing.html b/docs/releasing.html > index 07f100caae1..20fc4579a32 100644 > --- a/docs/releasing.html > +++ b/docs/releasing.html > @@ -249,6 +249,25 @@ Now go to > href="https://bugs.freedesktop.org/editversions.cgi?action=add&product=Mesa"; > target="_parent">Bugzilla and add the new Mesa version X.Y. > > > + > +Use a stanging branch: > + > + > +git checkout X.Y > +git checkout -b X.Y-proposed > + > + > +This branch should be reported to any teams using a CI to track upcoming > stable > +branches. This will allow that team to report an CI regressions to the > release > +manager, while leaving the X.Y branch in a continuously usable state. To > +that end it is most useful if the release manager run the relavent scripts > +(such as git-fixes-pick-list.sh) once per day, and update this branch. When > it is > +time to make a release, the X.Y branch should be rebased to the X.Y-proposed > branch. > + > +The staging branch can be force pushed (for example, to remove a patch that > +causes regressions), while the X.Y should not be force pushed. > + > + > > Check that there are no distribution breaking changes and revert them if > needed. > For example: files being overwritten on install, etc. Happens extremely > rarely - ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] docs: add news notes to 18.1.0
CC: Dylan Baker --- docs/index.html | 7 +++ 1 file changed, 7 insertions(+) diff --git a/docs/index.html b/docs/index.html index 5644ead731a..34418e9bdc8 100644 --- a/docs/index.html +++ b/docs/index.html @@ -16,6 +16,13 @@ News +May 18, 2018 + +Mesa 18.1.0 is released. This is a +new development release. See the release notes for more information +about the release. + + May 17, 2018 Mesa 18.0.4 is released. -- 2.17.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] docs: update release calendar for 18.1 series
CC: Andres Gomez CC: Emil Velikov CC: Dylan Baker --- As per calendar 18.2.0rc1 starts after the last 18.1.x release, either we need to update the release calendar for 18.2 series, or extend 18.1 series. docs/release-calendar.html | 34 +- 1 file changed, 5 insertions(+), 29 deletions(-) diff --git a/docs/release-calendar.html b/docs/release-calendar.html index ba297532dc3..c67eea1a9de 100644 --- a/docs/release-calendar.html +++ b/docs/release-calendar.html @@ -46,50 +46,26 @@ if you'd like to nominate a patch in the next stable release. Last planned 18.0.x release -18.1 -2018-04-20 -18.1.0rc1 -Dylan Baker - - - -2018-04-27 -18.1.0rc2 -Dylan Baker - - - -2018-05-04 -18.1.0rc3 -Dylan Baker - - - -2018-05-11 -18.1.0rc4 -Dylan Baker -Last planned RC/Final release - - -TBD +18.1 +2018-06-01 18.1.1 Emil Velikov -TBD +2018-06-15 18.1.2 Emil Velikov -TBD +2018-06-29 18.1.3 Emil Velikov -TBD +2018-07-13 18.1.4 Emil Velikov Last planned RC/Final release -- 2.17.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4.16 039/110] drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk
Sorry for top-posting, but why is this email on mesa-dev, and not on
intel-gfx? I mean, the latter is for the kernel driver while the former
is the userspace 3d driver, so intel-...@lists.freedesktop.org is
definitely the prefered mailing list for these discussions.
Martin
On 21/05/18 14:11, Greg Kroah-Hartman wrote:
> 4.16-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Michel Thierry
>
> commit b579f924a90f42fa561afd8201514fc216b71949 upstream.
>
> Factor in clear values wherever required while updating destination
> min/max.
>
> References: HSDES#160184
> Signed-off-by: Michel Thierry
> Cc: mesa-dev@lists.freedesktop.org
> Cc: Mika Kuoppala
> Cc: Oscar Mateo
> Reviewed-by: Mika Kuoppala
> Signed-off-by: Chris Wilson
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20180510200708.18097-1-michel.thie...@intel.com
> Cc: sta...@vger.kernel.org
> Cc: Joonas Lahtinen
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20180514165445.9198-1-michel.thie...@intel.com
> (backported from commit 0c79f9cb77eae28d48a4f9fc1b3341aacbbd260c)
> Signed-off-by: Joonas Lahtinen
> Signed-off-by: Greg Kroah-Hartman
>
> ---
> drivers/gpu/drm/i915/i915_reg.h|3 +++
> drivers/gpu/drm/i915/intel_engine_cs.c |4
> 2 files changed, 7 insertions(+)
>
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7139,6 +7139,9 @@ enum {
> #define SLICE_ECO_CHICKEN0 _MMIO(0x7308)
> #define PIXEL_MASK_CAMMING_DISABLE (1 << 14)
>
> +#define GEN9_WM_CHICKEN3 _MMIO(0x5588)
> +#define GEN9_FACTOR_IN_CLR_VAL_HIZ (1 << 9)
> +
> /* WaCatErrorRejectionIssue */
> #define GEN7_SQ_CHICKEN_MBCUNIT_CONFIG _MMIO(0x9030)
> #define GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB(1<<11)
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -1098,6 +1098,10 @@ static int gen9_init_workarounds(struct
> WA_SET_FIELD_MASKED(GEN8_CS_CHICKEN1, GEN9_PREEMPT_GPGPU_LEVEL_MASK,
> GEN9_PREEMPT_GPGPU_COMMAND_LEVEL);
>
> + /* WaClearHIZ_WM_CHICKEN3:bxt,glk */
> + if (IS_GEN9_LP(dev_priv))
> + WA_SET_BIT_MASKED(GEN9_WM_CHICKEN3, GEN9_FACTOR_IN_CLR_VAL_HIZ);
> +
> /* WaVFEStateAfterPipeControlwithMediaStateClear:skl,bxt,glk,cfl */
> ret = wa_ring_whitelist_reg(engine, GEN9_CTX_PREEMPT_REG);
> if (ret)
>
>
> ___
> 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 106511] radv: MSAA broken on SI (assertion failure in vkCreateImage)
https://bugs.freedesktop.org/show_bug.cgi?id=106511 --- Comment #3 from Turo Lamminen --- That patch works. Tested-by: Turo Lamminen -- 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 106595] [RADV] Rendering distortions only when MSAA is enabled
https://bugs.freedesktop.org/show_bug.cgi?id=106595 --- Comment #4 from Samuel Pitoiset --- Can you try https://patchwork.freedesktop.org/patch/224584/ then? -- 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-stable] [PATCH 01/17] i965/miptree: Fix handling of uninitialized MCS buffers
On Thu, 2018-05-17 at 14:01 -0700, Nanley Chery wrote:
> On Thu, May 17, 2018 at 09:25:18AM -0700, Dylan Baker wrote:
> > Quoting Nanley Chery (2018-05-03 12:03:48)
> > > Before this patch, if we failed to initialize an MCS buffer, we'd
> > > end up in a state in which the miptree thinks it has an MCS buffer,
> > > but doesn't. We also leaked the clear_color_bo if it existed.
> > >
> > > With this patch, we now free the miptree aux buffer resources and let
> > > intel_miptree_alloc_mcs() know that the MCS buffer no longer exists.
> > >
> > > Cc:
> > > ---
> > > src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 14 +++---
> > > 1 file changed, 7 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > index b9a564552df..377efae32c9 100644
> > > --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > @@ -1658,7 +1658,7 @@ intel_miptree_copy_teximage(struct brw_context *brw,
> > > intel_obj->needs_validate = true;
> > > }
> > >
> > > -static void
> > > +static bool
> > > intel_miptree_init_mcs(struct brw_context *brw,
> > > struct intel_mipmap_tree *mt,
> > > int init_value)
> > > @@ -1678,13 +1678,14 @@ intel_miptree_init_mcs(struct brw_context *brw,
> > > void *map = brw_bo_map(brw, mt->aux_buf->bo, MAP_WRITE | MAP_RAW);
> > > if (unlikely(map == NULL)) {
> > >fprintf(stderr, "Failed to map mcs buffer into GTT\n");
> > > - brw_bo_unreference(mt->aux_buf->bo);
> > > - free(mt->aux_buf);
> > > - return;
> > > + intel_miptree_aux_buffer_free(mt->aux_buf);
> > > + mt->aux_buf = NULL;
> > > + return false;
> > > }
> > > void *data = map;
> > > memset(data, init_value, mt->aux_buf->size);
> > > brw_bo_unmap(mt->aux_buf->bo);
> > > + return true;
> > > }
> > >
> > > static struct intel_miptree_aux_buffer *
> > > @@ -1764,15 +1765,14 @@ intel_miptree_alloc_mcs(struct brw_context *brw,
> > > const uint32_t alloc_flags = 0;
> > > mt->aux_buf = intel_alloc_aux_buffer(brw, "mcs-miptree",
> > > &temp_mcs_surf, alloc_flags, mt);
> > > - if (!mt->aux_buf) {
> > > + if (!mt->aux_buf ||
> > > + !intel_miptree_init_mcs(brw, mt, 0xFF)) {
> > >free(aux_state);
> > >return false;
> > > }
> > >
> > > mt->aux_state = aux_state;
> > >
> > > - intel_miptree_init_mcs(brw, mt, 0xFF);
> > > -
> > > return true;
> > > }
> > >
> > > --
> > > 2.16.2
> > >
> > > ___
> > > mesa-stable mailing list
> > > mesa-sta...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-stable
> >
> >
> > Hi Nanley,
> >
> > Neither this patch or the next one cleanly apply to the 18.1 branch (or, I
> > assume, 18.0), it looks like this depends on
> > af4e9295febe966ace7793e43ba35705521749e8, which was not CC'd to stable. I'm
> > not
> > sure how to resolve the rebase conflicts, what would you like to do?
> >
>
> Hi Dylan,
>
> I'd like to cherry-pick af4e9295febe966ace7793e43ba35705521749e8 and
> it's parent for 18.1. We can ignore 18.0. Sorry for not checking on this
> in advance.
>
Thanks, Nanley.
I'll leave this patch out for next 18.0 release.
J.A.
> -Nanley
>
> > Dylan
>
>
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 106595] [RADV] Rendering distortions only when MSAA is enabled
https://bugs.freedesktop.org/show_bug.cgi?id=106595 --- Comment #5 from zefkerri...@gmail.com --- (In reply to Samuel Pitoiset from comment #4) > Can you try https://patchwork.freedesktop.org/patch/224584/ then? Thank you! This really partially corrected this issue, but unfortunately not completely but only partially. -- 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 106595] [RADV] Rendering distortions only when MSAA is enabled
https://bugs.freedesktop.org/show_bug.cgi?id=106595 --- Comment #6 from zefkerri...@gmail.com --- Created attachment 139676 --> https://bugs.freedesktop.org/attachment.cgi?id=139676&action=edit I mean, some of the rendering distortion has disappeared. That is, I no longer see these distortions: I mean, some of the rendering distortion has disappeared. That is, I no longer see these distortions: -- 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 106595] [RADV] Rendering distortions only when MSAA is enabled
https://bugs.freedesktop.org/show_bug.cgi?id=106595 --- Comment #7 from zefkerri...@gmail.com --- Created attachment 139677 --> https://bugs.freedesktop.org/attachment.cgi?id=139677&action=edit But instead of this now after applying this patch, all the distortions with all modes (MSAAx2, MSAAx4, MSAAx8) look like this: -- 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 106595] [RADV] Rendering distortions only when MSAA is enabled
https://bugs.freedesktop.org/show_bug.cgi?id=106595 --- Comment #8 from zefkerri...@gmail.com --- Created attachment 139678 --> https://bugs.freedesktop.org/attachment.cgi?id=139678&action=edit I remind that if everything is correct then it should look like this: -- 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 106595] [RADV] Rendering distortions only when MSAA is enabled
https://bugs.freedesktop.org/show_bug.cgi?id=106595 zefkerri...@gmail.com changed: What|Removed |Added Attachment #139678|I remind that if everything |I remind you that if description|is correct then it should |everything is correct then |look like this: |it should look like this: -- 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-stable] [PATCH 02/17] i965/miptree: Zero-initialize CCS_D buffers
On Thu, 2018-05-03 at 14:22 -0700, Nanley Chery wrote:
> On Thu, May 03, 2018 at 12:40:49PM -0700, Jason Ekstrand wrote:
> > Good catch. Rb
> >
>
> Thanks!
>
> > On May 3, 2018 12:04:59 Nanley Chery wrote:
> >
> > > Before this patch, the aux_state was actually AUX_INVALID because the BO
> > > was never defined. This was fine on single slice miptrees because we
> > > would fast-clear the resource right after creation. For multi-slice
> > > miptrees on SKL+ however, this results in undefined behavior when
> > > accessing a non-base slice. Here's a specific example:
> > >
> > > 1) Fast clear level 0
> > > * Undefined CCS_D buffer allocated in "PASS_THROUGH" state.
> > > * Level 0 transitions to the CLEAR state.
> > > 2) Render to level 1
> > > * Level 1 may have a 2-bit pattern of 2's.
> > > * Rendering with a 2 in the CCS is undefined.
> > >
> > > Cc:
This patch does not apply cleanly in 18.0, so I've resolved the trivial
conflict:
https://github.com/Igalia/release-mesa/commit/3b7134c5350df5fcc04b71d9598154bbc6
451256
J.A.
> > > ---
> > > src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 10 --
> > > 1 file changed, 4 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > index 377efae32c9..182a896e23a 100644
> > > --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > @@ -1806,13 +1806,11 @@ intel_miptree_alloc_ccs(struct brw_context *brw,
> > > * A CCS value of 0 indicates that the corresponding block is in the
> > > * pass-through state which is what we want.
> > > *
> > > -* For CCS_D, on the other hand, we don't care as we're about to
> > > perform a
> > > -* fast-clear operation. In that case, being hot in caches more
> > > useful.
> > > +* For CCS_D, do the same thing. On gen9+, this avoids having any
> > > undefined
> > > +* bits in the aux buffer.
> > > */
> > > - const uint32_t alloc_flags = mt->aux_usage == ISL_AUX_USAGE_CCS_E ?
> > > -BO_ALLOC_ZEROED : BO_ALLOC_BUSY;
> > > - mt->aux_buf = intel_alloc_aux_buffer(brw, "ccs-miptree",
> > > -&temp_ccs_surf, alloc_flags, mt);
> > > + mt->aux_buf = intel_alloc_aux_buffer(brw, "ccs-miptree",
> > > &temp_ccs_surf,
> > > +BO_ALLOC_ZEROED, mt);
> > >if (!mt->aux_buf) {
> > > free(aux_state);
> > > return false;
> > > --
> > > 2.16.2
> > >
> > > ___
> > > mesa-dev mailing list
> > > mesa-dev@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
> >
> >
>
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/22] intel/compiler: implement 16-bit multiply-add
On Mon, 2018-05-21 at 13:49 +0300, Eero Tamminen wrote: > Hi, > > On 21.05.2018 10:42, Iago Toral wrote: > > On Fri, 2018-05-18 at 12:08 +0300, Eero Tamminen wrote: > > > On 17.05.2018 14:25, Eero Tamminen wrote: > > > > On 17.05.2018 11:46, Iago Toral Quiroga wrote: > > > > > The PRM for MAD states that F, DF and HF are supported, > > > > > however, > > > > > then > > > > > it requires that the instruction includes a 2-bit mask > > > > > specifying > > > > > the types of each operand like this: > > > > > > > > > > > > > > 00: 32-bit float > > > > > 01: 32-bit signed integer > > > > > 10: 32-bit unsigned integer > > > > > 11: 64-bit float > > > > > > > > Where this was? > > > > This is in the decription of the MAD instruction here (for SKL): > > > > https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc > > -skl > > -vol02a-commandreference-instructions.pdf > > > > It guess the contents for this were copy & pasted from previous > > PRMs > > that didn't support HF... > > Ouch. That looks pretty different from what's in here: > https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-s > kl-vol07-3d_media_gpgpu.pdf > > > > > In > > > > https://01.org/sites/default/files/documentation/intel-gfx-bspe > > > > c-os > > > > rc-chv-bsw-vol07-3d-media-gpgpu-engine.pdf > > I'll ask around who's currently maintaining the 01.org docs, and > could > she/he update the opcode docs. All of them from BSW to KBL seem to > have > the old information, while the Media GPGPU docs have newer info. Thanks Eero! > > Btw. Did you have test-cases utilizing mad() instructions, and did > they work OK with your patchset? Yes, but they only worked because I was dropping the MAD and open coding it as MUL+ADD for HF operands. > (If yes, better test-cases may be required.) The existing tests catch the problem if I don't attempt to lower the MAD for HF, so they are good enough for this. BTW, I implemented the solution using the Src1Type and Src2Type bits and it seems to work fine in BDW as well. Iago > > > > > Section "EU Changes by Processor Generation" states: > > > > - > > > > These features or behaviors are added for CHV, BSW, continuing > > > > to > > > > later generations: > > > > ... > > > > In the 3-source instruction format, widen the SrcType and > > > > DstType > > > > fields > > > > and add an encoding for the HF (Half Float) type. > > > > - > > > > > > > > (I.e. it applies to GEN9+ [1] and on GEN8 for BSW/CHV.) > > > > Actually, I have just verified that the BDW PRMs have the exact > > same > > thing, but stating BDW instead of BSW/CHV, so I guess BDW should be > > supported too. > > Yes, right. > > > > > > In section "GEN Instruction Format – 3-src" table, both "Dst > > > > Type" > > > > and > > > > "Src Type" fields are 3 bits, and there's additional 1 bit > > > > "Src1 > > > > Type" > > > > and "Src2 Type" fields to differentiate formats for src1 & > > > > src2. > > > > > > > > > > > Then, when looking at "Source or Destination Operand Fields > > > > (Alphabetically by Short Name)" section: > > > > --- > > > > DstType: > > > > > > > > Encoding for three source instructions: > > > > 000b = :f. Single precision Float (32-bit). > > > > 001b = :d. Signed Doubleword integer. > > > > 010b = :ud. Unsigned Doubleword integer. > > > > 011b = :df. Double precision Float (64-bit). > > > > 100b = :hf. Half precision Float (16-bit). > > > > 101b - 111b. Reserved. > > > > > > > > ... > > > > > > > > SrcType: > > > > > > > > Three source instructions use one SrcType field for all source > > > > operands, > > > > with a 3-bit encoding that allows fewer data types: > > > > > > > > Encoding for three source instructions: > > > > 000b = :f. Single precision Float (32-bit). > > > > 001b = :d. Signed Doubleword integer. > > > > 010b = :ud. Unsigned Doubleword integer. > > > > 011b = :df. Double precision Float (64-bit). > > > > 100b = :hf. Half precision Float (16-bit). > > > > 101b - 111b. Reserved. > > > > > > > > Three source instructions can use operands with mixed-mode > > > > precision. > > > > When SrcType field is set to :f or :hf it defines precision for > > > > source 0 > > > > only, and fields Src1Type and Src2Type define precision for > > > > other > > > > source > > > > operands: > > > > 0b = :f. Single precision Float (32-bit). > > > > 1b = :hf. Half precision Float (16-bit). > > > > --- > > > > > > Note also the section "Special Requirements for Handling Mixed > > > Mode > > > Float Operations". > > Both BDW & BSW specs list also this restriction, which is lifted > GEN9: > * Calculations using the HF (Half Float) type do not support > denormals > or gradual underflow. > > > > > Btw. Mesa supporting HF with mad() is important because pln() > > > doesn't support it in HW, but you can implement pln() HF version > > > with two mad()s.
Re: [Mesa-dev] [PATCH mesa] i965: Check result of make_surface() for miptree_create
On Monday, 2018-05-21 11:42:37 -0700, Ian Romanick wrote:
> On 05/17/2018 05:05 AM, Eric Engestrom wrote:
> > From: Andrea Azzarone
> >
> > Since make_surface() can fail we need to check the result before
> > dereferencing it.
> >
> > Bug: https://github.com/mesa3d/mesa/pull/5
> > Bug: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1760415
> > Reviewed-by: Eric Engestrom
> > ---
> > Andrea: We don't use github, I only happened to notice your pull request :)
> > Next time you want to send us something, send it here :P
> > ---
> > src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > index 67086ee6c0e8d6b6feb0..43687ea77abfe9989882 100644
> > --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > @@ -718,6 +718,9 @@ miptree_create(struct brw_context *brw,
> > ISL_SURF_USAGE_DEPTH_BIT | ISL_SURF_USAGE_TEXTURE_BIT,
> > BO_ALLOC_BUSY, 0, NULL);
> >
> > + if (!mt)
> > + return NULL;
> > +
>
> So... I sent this same patch a few months ago, but we decided to not
> land it.
>
> https://patchwork.freedesktop.org/patch/195626/
Right, I had missed that discussion.
Dropping the patch :)
>
>
> >if (needs_separate_stencil(brw, mt, format) &&
> >!make_separate_stencil_surface(brw, mt)) {
> > intel_miptree_release(&mt);
> >
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] llvmpipe: improve rasterization discard logic
Am 22.05.2018 um 05:01 schrieb Brian Paul:
> On 05/21/2018 07:34 PM, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> This unifies the explicit rasterization dicard as well as the implicit
>
> "discard"
Right.
>
> Looks OK to me. Minor nits below.
>
> Reviewed-by: Brian Paul
>
>
>> rasterization disabled logic (which we need for another state tracker),
>> which really should do the exact same thing.
>> We'll now toss out the prims early on in setup with (implicit or
>> explicit) discard, rather than do setup and binning with them, which
>> was entirely pointless.
>> (We should eventually get rid of implicit discard, which should also
>> enable us to discard stuff already in draw, hence draw would be
>> able to skip the pointless clip and fallback stages in this case.)
>> We still need separate logic for only null ps - this is not the same
>> as rasterization discard. But simplify the logic there and don't count
>> primitives simply when there's an empty fs, regardless of depth/stencil
>> tests, which seems perfectly acceptable by d3d10.
>> While here, also fix statistics for primitives if face culling is
>> enabled.
>> No piglit changes.
>> ---
>> src/gallium/drivers/llvmpipe/lp_context.h | 1 -
>> src/gallium/drivers/llvmpipe/lp_jit.c | 1 +
>> src/gallium/drivers/llvmpipe/lp_jit.h | 5 +++
>> src/gallium/drivers/llvmpipe/lp_rast.c | 12 +++-
>> src/gallium/drivers/llvmpipe/lp_rast_priv.h | 6
>> src/gallium/drivers/llvmpipe/lp_scene.c | 5 ++-
>> src/gallium/drivers/llvmpipe/lp_scene.h | 10 +++---
>> src/gallium/drivers/llvmpipe/lp_setup.c | 18 ++-
>> src/gallium/drivers/llvmpipe/lp_setup_line.c | 27 ++--
>> src/gallium/drivers/llvmpipe/lp_setup_point.c | 21 +
>> src/gallium/drivers/llvmpipe/lp_setup_tri.c | 29 -
>> src/gallium/drivers/llvmpipe/lp_setup_vbuf.c | 2 +-
>> src/gallium/drivers/llvmpipe/lp_state_derived.c | 22 ++---
>> src/gallium/drivers/llvmpipe/lp_state_fs.c | 41
>> -
>> src/gallium/drivers/llvmpipe/lp_state_fs.h | 5 ---
>> 15 files changed, 118 insertions(+), 87 deletions(-)
>>
>> diff --git a/src/gallium/drivers/llvmpipe/lp_context.h
>> b/src/gallium/drivers/llvmpipe/lp_context.h
>> index 54d98fd..7a2f253 100644
>> --- a/src/gallium/drivers/llvmpipe/lp_context.h
>> +++ b/src/gallium/drivers/llvmpipe/lp_context.h
>> @@ -136,7 +136,6 @@ struct llvmpipe_context {
>> struct blitter_context *blitter;
>> unsigned tex_timestamp;
>> - boolean no_rast;
>> /** List of all fragment shader variants */
>> struct lp_fs_variant_list_item fs_variants_list;
>> diff --git a/src/gallium/drivers/llvmpipe/lp_jit.c
>> b/src/gallium/drivers/llvmpipe/lp_jit.c
>> index a2762f3..e2309f4 100644
>> --- a/src/gallium/drivers/llvmpipe/lp_jit.c
>> +++ b/src/gallium/drivers/llvmpipe/lp_jit.c
>> @@ -212,6 +212,7 @@ lp_jit_create_types(struct
>> lp_fragment_shader_variant *lp)
>> elem_types[LP_JIT_THREAD_DATA_CACHE] =
>> LLVMPointerType(lp_build_format_cache_type(gallivm), 0);
>> elem_types[LP_JIT_THREAD_DATA_COUNTER] =
>> LLVMInt64TypeInContext(lc);
>> + elem_types[LP_JIT_THREAD_DATA_INVOCATIONS] =
>> LLVMInt64TypeInContext(lc);
>> elem_types[LP_JIT_THREAD_DATA_RASTER_STATE_VIEWPORT_INDEX] =
>> LLVMInt32TypeInContext(lc);
>> diff --git a/src/gallium/drivers/llvmpipe/lp_jit.h
>> b/src/gallium/drivers/llvmpipe/lp_jit.h
>> index 9db26f2..312d1a1 100644
>> --- a/src/gallium/drivers/llvmpipe/lp_jit.h
>> +++ b/src/gallium/drivers/llvmpipe/lp_jit.h
>> @@ -192,6 +192,7 @@ struct lp_jit_thread_data
>> {
>> struct lp_build_format_cache *cache;
>> uint64_t vis_counter;
>> + uint64_t ps_invocations;
>> /*
>> * Non-interpolated rasterizer state passed through to the
>> fragment shader.
>> @@ -205,6 +206,7 @@ struct lp_jit_thread_data
>> enum {
>> LP_JIT_THREAD_DATA_CACHE = 0,
>> LP_JIT_THREAD_DATA_COUNTER,
>> + LP_JIT_THREAD_DATA_INVOCATIONS,
>> LP_JIT_THREAD_DATA_RASTER_STATE_VIEWPORT_INDEX,
>> LP_JIT_THREAD_DATA_COUNT
>> };
>> @@ -216,6 +218,9 @@ enum {
>> #define lp_jit_thread_data_counter(_gallivm, _ptr) \
>> lp_build_struct_get_ptr(_gallivm, _ptr,
>> LP_JIT_THREAD_DATA_COUNTER, "counter")
>> +#define lp_jit_thread_data_invocations(_gallivm, _ptr) \
>> + lp_build_struct_get_ptr(_gallivm, _ptr,
>> LP_JIT_THREAD_DATA_INVOCATIONS, "invocs")
>> +
>> #define lp_jit_thread_data_raster_state_viewport_index(_gallivm,
>> _ptr) \
>> lp_build_struct_get(_gallivm, _ptr, \
>>
>> LP_JIT_THREAD_DATA_RASTER_STATE_VIEWPORT_INDEX, \
>> diff --git a/src/gallium/drivers/llvmpipe/lp_rast.c
>> b/src/gallium/drivers/llvmpipe/lp_rast.c
>> index 939944a..9d4f9f8 100644
>> --- a/src/gallium/drivers/llvmpipe/lp_rast.c
>> +++ b/src/gallium/drivers/llvmpipe
Re: [Mesa-dev] [Mesa-stable] [PATCH 02/17] i965/miptree: Zero-initialize CCS_D buffers
On Tue, May 22, 2018 at 01:09:18PM +0200, Juan A. Suarez Romero wrote:
> On Thu, 2018-05-03 at 14:22 -0700, Nanley Chery wrote:
> > On Thu, May 03, 2018 at 12:40:49PM -0700, Jason Ekstrand wrote:
> > > Good catch. Rb
> > >
> >
> > Thanks!
> >
> > > On May 3, 2018 12:04:59 Nanley Chery wrote:
> > >
> > > > Before this patch, the aux_state was actually AUX_INVALID because the BO
> > > > was never defined. This was fine on single slice miptrees because we
> > > > would fast-clear the resource right after creation. For multi-slice
> > > > miptrees on SKL+ however, this results in undefined behavior when
> > > > accessing a non-base slice. Here's a specific example:
> > > >
> > > > 1) Fast clear level 0
> > > > * Undefined CCS_D buffer allocated in "PASS_THROUGH" state.
> > > > * Level 0 transitions to the CLEAR state.
> > > > 2) Render to level 1
> > > > * Level 1 may have a 2-bit pattern of 2's.
> > > > * Rendering with a 2 in the CCS is undefined.
> > > >
> > > > Cc:
>
>
> This patch does not apply cleanly in 18.0, so I've resolved the trivial
> conflict:
>
>
> https://github.com/Igalia/release-mesa/commit/3b7134c5350df5fcc04b71d9598154bbc6
> 451256
>
Looks good to me. Thanks for getting this into 18.0.
-Nanley
> J.A.
>
>
> > > > ---
> > > > src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 10 --
> > > > 1 file changed, 4 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > > b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > > index 377efae32c9..182a896e23a 100644
> > > > --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > > +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > > @@ -1806,13 +1806,11 @@ intel_miptree_alloc_ccs(struct brw_context *brw,
> > > > * A CCS value of 0 indicates that the corresponding block is in the
> > > > * pass-through state which is what we want.
> > > > *
> > > > -* For CCS_D, on the other hand, we don't care as we're about to
> > > > perform a
> > > > -* fast-clear operation. In that case, being hot in caches more
> > > > useful.
> > > > +* For CCS_D, do the same thing. On gen9+, this avoids having any
> > > > undefined
> > > > +* bits in the aux buffer.
> > > > */
> > > > - const uint32_t alloc_flags = mt->aux_usage == ISL_AUX_USAGE_CCS_E ?
> > > > -BO_ALLOC_ZEROED : BO_ALLOC_BUSY;
> > > > - mt->aux_buf = intel_alloc_aux_buffer(brw, "ccs-miptree",
> > > > -&temp_ccs_surf, alloc_flags,
> > > > mt);
> > > > + mt->aux_buf = intel_alloc_aux_buffer(brw, "ccs-miptree",
> > > > &temp_ccs_surf,
> > > > +BO_ALLOC_ZEROED, mt);
> > > >if (!mt->aux_buf) {
> > > > free(aux_state);
> > > > return false;
> > > > --
> > > > 2.16.2
> > > >
> > > > ___
> > > > mesa-dev mailing list
> > > > mesa-dev@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > >
> > >
> > >
> >
> > ___
> > mesa-stable mailing list
> > mesa-sta...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-stable
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/miptree: Fail gracefully when make_surface returns NULL
On Wed, Jan 03, 2018 at 10:41:43AM -0800, Ian Romanick wrote:
> From: Ian Romanick
>
> Every other caller of make_surface does something sensible when NULL is
> returned.
>
> Signed-off-by: Ian Romanick
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104214
I think it'd be helpful to add/use this tag which shows the specific
issue out in the wild:
Bug: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1760415
> Tested-by: Cyril
> Cc: "17.3"
I think this fixes tag should catch all relevant stable releases:
Fixes: 67b53ee4183 "i965: Represent depth surfaces with isl"
With at least the fixes tag, this patch is
Reviewed-by: Nanley Chery
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index ead0c35..0079a08 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -719,6 +719,9 @@ miptree_create(struct brw_context *brw,
> ISL_SURF_USAGE_DEPTH_BIT | ISL_SURF_USAGE_TEXTURE_BIT,
> BO_ALLOC_BUSY, 0, NULL);
>
> + if (mt == NULL)
> + return NULL;
> +
>if (needs_separate_stencil(brw, mt, format) &&
>!make_separate_stencil_surface(brw, mt)) {
> intel_miptree_release(&mt);
> --
> 2.9.5
>
> ___
> 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 1/2] bin/bugzilla_mesa.sh: explicitly set the --pretty argument
On Monday, May 21, 2018 10:32:04 AM PDT Dylan Baker wrote: > Signed-off-by: Dylan Baker > --- > bin/bugzilla_mesa.sh | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/bin/bugzilla_mesa.sh b/bin/bugzilla_mesa.sh > index a8f5305844b..9095bc9deea 100755 > --- a/bin/bugzilla_mesa.sh > +++ b/bin/bugzilla_mesa.sh > @@ -23,7 +23,7 @@ echo "" > echo "" > > # extract fdo urls from commit log > -git log $* | grep 'bugs.freedesktop.org/show_bug' | sed -e $trim_before | > sort -n -u | sed -e $use_after |\ > +git log --pretty=medium $* | grep 'bugs.freedesktop.org/show_bug' | sed -e > $trim_before | sort -n -u | sed -e $use_after |\ > while read url > do > id=$(echo $url | cut -d'=' -f2) > Series is: Reviewed-by: Kenneth Graunke 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
[Mesa-dev] [Bug 106619] [OpenCL][llvm-svn]build failure addPassesToEmitFile candidate expects 6 arguments, 3 provided
https://bugs.freedesktop.org/show_bug.cgi?id=106619 Bug ID: 106619 Summary: [OpenCL][llvm-svn]build failure addPassesToEmitFile candidate expects 6 arguments, 3 provided Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Other Assignee: mesa-dev@lists.freedesktop.org Reporter: lonew...@xs4all.nl QA Contact: mesa-dev@lists.freedesktop.org Created attachment 139683 --> https://bugs.freedesktop.org/attachment.cgi?id=139683&action=edit build log Both autotools and meson give the same error. Archlinux, gcc 8.1 , llvm-svn rev 332974 , mesa-git fe2edb25dd for configure settings see https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mesa-git Full build log attached, last relevant line : llvm/codegen/native.cpp:135:49: error: no matching function for call to ‘llvm::TargetMachine::addPassesToEmitFile(clover::llvm::compat::pass_manager&, llvm::raw_svector_ostream&, llvm::TargetMachine::CodeGenFileType&)’ if (tm->addPassesToEmitFile(pm, fos, ft)) ^ In file included from ./llvm/compat.hpp:50, from llvm/codegen/native.cpp:31: /usr/include/llvm/Target/TargetMachine.h:254:16: note: candidate: ‘virtual bool llvm::TargetMachine::addPassesToEmitFile(llvm::legacy::PassManagerBase&, llvm::raw_pwrite_stream&, llvm::raw_pwrite_stream*, llvm::TargetMachine::CodeGenFileType, bool, llvm::MachineModuleInfo*)’ virtual bool addPassesToEmitFile(PassManagerBase &, raw_pwrite_stream &, -- 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] bin/bugzilla_mesa.sh: explicitly set the --pretty argument
This series is: Reviewed-by: Andres Gomez On Mon, 2018-05-21 at 10:32 -0700, Dylan Baker wrote: > Signed-off-by: Dylan Baker > --- > bin/bugzilla_mesa.sh | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/bin/bugzilla_mesa.sh b/bin/bugzilla_mesa.sh > index a8f5305844b..9095bc9deea 100755 > --- a/bin/bugzilla_mesa.sh > +++ b/bin/bugzilla_mesa.sh > @@ -23,7 +23,7 @@ echo "" > echo "" > > # extract fdo urls from commit log > -git log $* | grep 'bugs.freedesktop.org/show_bug' | sed -e $trim_before | > sort -n -u | sed -e $use_after |\ > +git log --pretty=medium $* | grep 'bugs.freedesktop.org/show_bug' | sed -e > $trim_before | sort -n -u | sed -e $use_after |\ > while read url > do > id=$(echo $url | cut -d'=' -f2) -- Br, Andres ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Add ir_binop_vector_extract in NIR
Gently ping to get a review for this patch.
J.A.
On Thu, 2018-05-10 at 10:59 +0200, Juan A. Suarez Romero wrote:
> Implement ir_binop_vector_extract using NIR operations. Based on SPIR-V
> to NIR approach.
>
> This fixes:
> dEQP-GLES3.functional.shaders.indexing.moredynamic.with_value_from_indexing_expression_fragment
> Piglit's glsl-fs-vec4-indexing-8.shader_test
>
> Signed-off-by: Juan A. Suarez Romero
> ---
>
> Pending to verify that this also fixes
> https://bugs.freedesktop.org/show_bug.cgi?id=105438
>
> src/compiler/glsl/glsl_to_nir.cpp | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/src/compiler/glsl/glsl_to_nir.cpp
> b/src/compiler/glsl/glsl_to_nir.cpp
> index 8e5e9c34912..5fc420d856f 100644
> --- a/src/compiler/glsl/glsl_to_nir.cpp
> +++ b/src/compiler/glsl/glsl_to_nir.cpp
> @@ -1928,6 +1928,17 @@ nir_visitor::visit(ir_expression *ir)
> unreachable("not reached");
>}
>break;
> + case ir_binop_vector_extract: {
> + unsigned swiz[4] = { 0 };
> + result = nir_swizzle(&b, srcs[0], swiz, 1, true);
> + for (unsigned i = 1; i < ir->operands[0]->type->vector_elements; i++) {
> + swiz[0] = i;
> + nir_ssa_def *swizzled = nir_swizzle(&b, srcs[0], swiz, 1, true);
> + result = nir_bcsel(&b, nir_ieq(&b, srcs[1], nir_imm_int(&b, i)),
> +swizzled, result);
> + }
> + break;
> + }
>
> case ir_binop_ldexp: result = nir_ldexp(&b, srcs[0], srcs[1]); break;
> case ir_triop_fma:
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH mesa] vulkan: don't free uninitialised memory
The modifiers array hasn't been initialised by then, much less with data that would need freeing. Move the label after the loop to fix this. Signed-off-by: Eric Engestrom --- src/vulkan/wsi/wsi_common_x11.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/vulkan/wsi/wsi_common_x11.c b/src/vulkan/wsi/wsi_common_x11.c index 62739b99125412ec9d73..1bfbc7c30019a63b6599 100644 --- a/src/vulkan/wsi/wsi_common_x11.c +++ b/src/vulkan/wsi/wsi_common_x11.c @@ -1421,10 +1421,10 @@ x11_surface_create_swapchain(VkIcdSurfaceBase *icd_surface, for (uint32_t j = 0; j < image; j++) x11_image_finish(chain, pAllocator, &chain->images[j]); + for (int i = 0; i < ARRAY_SIZE(modifiers); i++) + vk_free(pAllocator, modifiers[i]); + fail_register: - for (int i = 0; i < ARRAY_SIZE(modifiers); i++) - vk_free(pAllocator, modifiers[i]); - xcb_unregister_for_special_event(chain->conn, chain->special_event); wsi_swapchain_finish(&chain->base); -- Cheers, Eric ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 2/3] glsl: allow built-in variables to be explicitly declared
On 05/11/2018 09:49 PM, Timothy Arceri wrote:
> Mesa seems to be the only implementation that doesn't allow builtins
> to be explicitly declared. The GLSL 1.30 spec seems to imply that
> buitins may be explicitly declared.
There was a clarification added to the spec in response to a Khronos bug
that I submitted. I don't recall the version where it was added, but
the resulting text is in section 3.7 (Identifiers):
Identifiers starting with “gl_” are reserved for use by OpenGL, and
may not be declared in a shader; this results in a compile-time
error. However, as noted in the specification, there are some cases
where previously declared variables can be redeclared, and
predeclared "gl_" names are allowed to be redeclared in a shader
only for these specific purposes. More generally, it is a
compile-time error to redeclare a variable, including those starting
“gl_”.
The specific cases where redeclaration is allowed are cases where
invariant is added, precision qualifiers are added, an array size is
added, etc.
> This this allows the game "Full Bore" the be playable (when using
> MESA_GL_VERSION_OVERRIDE=3.3COMPAT). It will also allow us to
> remove the allow_glsl_builtin_variable_redeclaration dri override.
What is the nature of the redeclaration in this game? Does the shader
in question compile with glslang?
> From the GLSL 1.30 spec Section 7.2 (Fragment Shader Special
> Variables):
>
> "Both gl_FragColor and gl_FragData are deprecated; the preferred
> usage is to explicitly declare these outputs in the fragment
> shader using the out storage qualifier."
>
> To avoid some GLSL ES tests failing we add a check to make sure
> precision matches on the redeclared builtin.
> ---
> src/compiler/glsl/ast_to_hir.cpp | 32 ++--
> 1 file changed, 22 insertions(+), 10 deletions(-)
>
> diff --git a/src/compiler/glsl/ast_to_hir.cpp
> b/src/compiler/glsl/ast_to_hir.cpp
> index a7a9ac80769..54d0816a986 100644
> --- a/src/compiler/glsl/ast_to_hir.cpp
> +++ b/src/compiler/glsl/ast_to_hir.cpp
> @@ -4390,14 +4390,8 @@ get_variable_being_redeclared(ir_variable **var_ptr,
> YYLTYPE loc,
>earlier->data.precision = var->data.precision;
>earlier->data.memory_coherent = var->data.memory_coherent;
>
> - } else if (earlier->data.how_declared == ir_var_declared_implicitly &&
> - state->allow_builtin_variable_redeclaration) {
> - /* Allow verbatim redeclarations of built-in variables. Not explicitly
> - * valid, but some applications do it.
> - */
> - if (earlier->data.mode != var->data.mode &&
> - !(earlier->data.mode == ir_var_system_value &&
> -var->data.mode == ir_var_shader_in)) {
> + } else if (allow_all_redeclarations) {
> + if (earlier->data.mode != var->data.mode) {
> _mesa_glsl_error(&loc, state,
>"redeclaration of `%s' with incorrect qualifiers",
>var->name);
> @@ -4406,8 +4400,22 @@ get_variable_being_redeclared(ir_variable **var_ptr,
> YYLTYPE loc,
>"redeclaration of `%s' has incorrect type",
>var->name);
>}
> - } else if (allow_all_redeclarations) {
> - if (earlier->data.mode != var->data.mode) {
> + } else if (earlier->data.how_declared == ir_var_declared_implicitly) {
> + /* Allow verbatim redeclarations of built-in variables. The GLSL 1.30
> + * spec seems to imply that buitins may be explicitly declared.
> + *
> + * From the GLSL 1.30 spec Section 7.2 (Fragment Shader Special
> + * Variables):
> + *
> + *"Both gl_FragColor and gl_FragData are deprecated; the preferred
> + *usage is to explicitly declare these outputs in the fragment
> + *shader using the out storage qualifier."
> + */
> + enum ir_variable_mode builtin_mode =
> + glsl_external_mode((ir_variable_mode) earlier->data.mode,
> +state->stage, earlier->data.location);
> +
> + if (builtin_mode != var->data.mode) {
> _mesa_glsl_error(&loc, state,
>"redeclaration of `%s' with incorrect qualifiers",
>var->name);
> @@ -4415,6 +4423,10 @@ get_variable_being_redeclared(ir_variable **var_ptr,
> YYLTYPE loc,
> _mesa_glsl_error(&loc, state,
>"redeclaration of `%s' has incorrect type",
>var->name);
> + } else if (earlier->data.precision != var->data.precision) {
> + _mesa_glsl_error(&loc, state,
> + "redeclaration of `%s' has incorrect precision",
> + var->name);
>}
> } else {
>_mesa_glsl_error(&loc, state, "`%s' redeclared", var->name);
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http
Re: [Mesa-dev] [PATCH mesa] vulkan: don't free uninitialised memory
On 22/05/18 18:02, Eric Engestrom wrote:
The modifiers array hasn't been initialised by then, much less with data
that would need freeing.
Move the label after the loop to fix this.
Signed-off-by: Eric Engestrom
Reviewed-by: Lionel Landwerlin
Fixes: c80c08e22603 ("vulkan/wsi/x11: Add support for DRI3 v1.2")
---
src/vulkan/wsi/wsi_common_x11.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/vulkan/wsi/wsi_common_x11.c b/src/vulkan/wsi/wsi_common_x11.c
index 62739b99125412ec9d73..1bfbc7c30019a63b6599 100644
--- a/src/vulkan/wsi/wsi_common_x11.c
+++ b/src/vulkan/wsi/wsi_common_x11.c
@@ -1421,10 +1421,10 @@ x11_surface_create_swapchain(VkIcdSurfaceBase
*icd_surface,
for (uint32_t j = 0; j < image; j++)
x11_image_finish(chain, pAllocator, &chain->images[j]);
+ for (int i = 0; i < ARRAY_SIZE(modifiers); i++)
+ vk_free(pAllocator, modifiers[i]);
+
fail_register:
- for (int i = 0; i < ARRAY_SIZE(modifiers); i++)
- vk_free(pAllocator, modifiers[i]);
-
xcb_unregister_for_special_event(chain->conn, chain->special_event);
wsi_swapchain_finish(&chain->base);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCHv2 3/4] i965: Handle non-zero texture buffer offsets in buffer object range calculation.
On Mon, May 21, 2018 at 05:32:09PM -0700, Francisco Jerez wrote: > Otherwise the specified surface state will allow the GPU to access > memory up to BufferOffset bytes past the end of the buffer. Found by > inspection. > > v2: Protect against out-of-range BufferOffset (Nanley). > Cc: mesa-sta...@lists.freedesktop.org > --- > src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c > b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c > index af629a17bfa..39e898243db 100644 > --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c > +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c > @@ -647,6 +647,7 @@ buffer_texture_range_size(struct brw_context *brw, > const unsigned texel_size = > _mesa_get_format_bytes(obj->_BufferObjectFormat); > const unsigned buffer_size = (!obj->BufferObject ? 0 : > obj->BufferObject->Size); > + const unsigned buffer_offset = MIN2(buffer_size, obj->BufferOffset); > Clamping the offset is a nice solution. This patch is Reviewed-by: Nanley Chery > /* The ARB_texture_buffer_specification says: > * > @@ -664,7 +665,8 @@ buffer_texture_range_size(struct brw_context *brw, > * so that when ISL divides by stride to obtain the number of texels, that > * texel count is clamped to MAX_TEXTURE_BUFFER_SIZE. > */ > - return MIN3((unsigned)obj->BufferSize, buffer_size, > + return MIN3((unsigned)obj->BufferSize, > + buffer_size - buffer_offset, > brw->ctx.Const.MaxTextureBufferSize * texel_size); > } > > -- > 2.16.1 > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] docs/releasing: add meson to build systems to test
I think this change should be completed with the corresponding additional instructions to "Perform basic testing", under the "Making a new release" section at: https://www.mesa3d.org/releasing.html#release On Mon, 2018-05-21 at 10:34 -0700, Dylan Baker wrote: > --- > docs/releasing.html | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/docs/releasing.html b/docs/releasing.html > index d69eba1136f..07f100caae1 100644 > --- a/docs/releasing.html > +++ b/docs/releasing.html > @@ -122,7 +122,7 @@ Currently Ilia Mirkin and AMD devs have requested > "permanent" exception. > > > > -make distcheck, scons and scons check must pass > +make distcheck, scons and scons check, and meson + ninja test must pass > Testing with different version of system components - LLVM and others is > also > performed where possible. > As a general rule, testing with various combinations of configure -- Br, Andres ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] docs/releasing: Add complete command line to scripts
This is: Reviewed-by: Andres Gomez On Mon, 2018-05-21 at 10:34 -0700, Dylan Baker wrote: > particularly that bugzilla_mesa and shortlog_mesa take an argument to > pass directly to git. > --- > docs/releasing.html | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/docs/releasing.html b/docs/releasing.html > index a022d0c484b..d69eba1136f 100644 > --- a/docs/releasing.html > +++ b/docs/releasing.html > @@ -547,8 +547,8 @@ Two scripts are available to help generate portions of > the release notes: > > > > - ./bin/bugzilla_mesa.sh > - ./bin/shortlog_mesa.sh > + ./bin/bugzilla_mesa.sh $previous_release_point..$current_release_point > + ./bin/shortlog_mesa.sh $previous_release_point..$current_release_point > > > -- Br, Andres ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] docs/releasing: Add note about using a staging branch
On Mon, 2018-05-21 at 10:34 -0700, Dylan Baker wrote: > --- > docs/releasing.html | 19 +++ > 1 file changed, 19 insertions(+) > > diff --git a/docs/releasing.html b/docs/releasing.html > index 07f100caae1..20fc4579a32 100644 > --- a/docs/releasing.html > +++ b/docs/releasing.html > @@ -249,6 +249,25 @@ Now go to > href="https://bugs.freedesktop.org/editversions.cgi?action=add&product=Mesa"; > target="_parent">Bugzilla and add the new Mesa version X.Y. > > > + > +Use a stanging branch: staging > + > + > +git checkout X.Y > +git checkout -b X.Y-proposed > + > + > +This branch should be reported to any teams using a CI to track upcoming > stable > +branches. This will allow that team to report an CI regressions to the > release those teams to report any^^ (already mentioned by Ian) > +manager, while leaving the X.Y branch in a continuously usable state. To > +that end it is most useful if the release manager run the relavent scripts relevant (already mentioned by Ian) > +(such as git-fixes-pick-list.sh) once per day, and update this branch. When > it is > +time to make a release, the X.Y branch should be rebased to the X.Y-proposed > branch. > + > +The staging branch can be force pushed (for example, to remove a patch that > +causes regressions), while the X.Y should not be force pushed. > + > + > > Check that there are no distribution breaking changes and revert them if > needed. > For example: files being overwritten on install, etc. Happens extremely > rarely - As commented by Juan, we are already using a staging branch in our own GitHub clone. If there is no problem in force pushing a branch in the freedesktop repository, it is OK with me, since we would only be just pushing there too. With the comment and the changes above, this is: Reviewed-by: Andres Gomez -- Br, Andres ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/miptree: Fail gracefully when make_surface returns NULL
On 05/22/2018 09:03 AM, Nanley Chery wrote:
> On Wed, Jan 03, 2018 at 10:41:43AM -0800, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> Every other caller of make_surface does something sensible when NULL is
>> returned.
>>
>> Signed-off-by: Ian Romanick
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104214
>
> I think it'd be helpful to add/use this tag which shows the specific
> issue out in the wild:
>
> Bug: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1760415
>
>> Tested-by: Cyril
>> Cc: "17.3"
>
> I think this fixes tag should catch all relevant stable releases:
>
> Fixes: 67b53ee4183 "i965: Represent depth surfaces with isl"
Okay... we previously had a case where make_surface would return NULL,
but we determined that this was because of a problem elsewhere. This
was fixed by 897c54d522ab9 (loader/dri3: Avoid freeing renderbuffers in
use).
Based on this fixes tag, am I correct that another scenario where
make_surface could fail was added later? Assuming that's correct, is
this actually the right fix or, as before, is it just papering over the
real issue?
> With at least the fixes tag, this patch is
> Reviewed-by: Nanley Chery
>
>> ---
>> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> index ead0c35..0079a08 100644
>> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> @@ -719,6 +719,9 @@ miptree_create(struct brw_context *brw,
>> ISL_SURF_USAGE_DEPTH_BIT | ISL_SURF_USAGE_TEXTURE_BIT,
>> BO_ALLOC_BUSY, 0, NULL);
>>
>> + if (mt == NULL)
>> + return NULL;
>> +
>>if (needs_separate_stencil(brw, mt, format) &&
>>!make_separate_stencil_surface(brw, mt)) {
>> intel_miptree_release(&mt);
>> --
>> 2.9.5
>>
>> ___
>> 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] docs: add news notes to 18.1.0
Oops, thanks for catching this. Reviewed-by: Dylan Baker Quoting Juan A. Suarez Romero (2018-05-22 00:34:23) > CC: Dylan Baker > --- > docs/index.html | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/docs/index.html b/docs/index.html > index 5644ead731a..34418e9bdc8 100644 > --- a/docs/index.html > +++ b/docs/index.html > @@ -16,6 +16,13 @@ > > News > > +May 18, 2018 > + > +Mesa 18.1.0 is released. This is a > +new development release. See the release notes for more information > +about the release. > + > + > May 17, 2018 > > Mesa 18.0.4 is released. > -- > 2.17.0 > signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: update release calendar for 18.1 series
This looks good to me. I'm also opened to doing the 18.1.x releases if Emil would rather not do them (and I have been updating my 18.1-proposed branch either way). Reviewed-by: Dylan Baker Quoting Juan A. Suarez Romero (2018-05-22 00:48:48) > CC: Andres Gomez > CC: Emil Velikov > CC: Dylan Baker > --- > > As per calendar 18.2.0rc1 starts after the last 18.1.x release, either > we need to update the release calendar for 18.2 series, or extend 18.1 > series. > > > docs/release-calendar.html | 34 +- > 1 file changed, 5 insertions(+), 29 deletions(-) > > diff --git a/docs/release-calendar.html b/docs/release-calendar.html > index ba297532dc3..c67eea1a9de 100644 > --- a/docs/release-calendar.html > +++ b/docs/release-calendar.html > @@ -46,50 +46,26 @@ if you'd like to nominate a patch in the next stable > release. > Last planned 18.0.x release > > > -18.1 > -2018-04-20 > -18.1.0rc1 > -Dylan Baker > - > - > - > -2018-04-27 > -18.1.0rc2 > -Dylan Baker > - > - > - > -2018-05-04 > -18.1.0rc3 > -Dylan Baker > - > - > - > -2018-05-11 > -18.1.0rc4 > -Dylan Baker > -Last planned RC/Final release > - > - > -TBD > +18.1 > +2018-06-01 > 18.1.1 > Emil Velikov > > > > -TBD > +2018-06-15 > 18.1.2 > Emil Velikov > > > > -TBD > +2018-06-29 > 18.1.3 > Emil Velikov > > > > -TBD > +2018-07-13 > 18.1.4 > Emil Velikov > Last planned RC/Final release > -- > 2.17.0 > signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] mesa 18.1.0
You're right, we'll get this fixed. Thanks for pointing it out! Dylan Quoting Stuart Young (2018-05-21 21:31:42) > Appears that while the release notes for 18.1.0 are actually up on the website > [1], the News[2] column on the main website didn't get updated, as 18.1.0 > isn't > listed there. > > > 1. https://www.mesa3d.org/relnotes/18.1.0.html > 2. https://www.mesa3d.org/index.html > > > On 19 May 2018 at 09:43, wrote: > > Mesa 18.1.0 is now available. > > Here is a short list of notable features compared to 18.0 > - OpenGL 3.1 with ARB_compatibility on nv50, nvc0, r600, radeonsi, > softpipe, llvmpipe, svga > - GL_ARB_bindless_texture on nvc0/maxwell+ > - GL_ARB_transform_feedback_overflow_query on nvc0 > - GL_EXT_semaphore on radeonsi > - GL_EXT_semaphore_fd on radeonsi > - GL_EXT_shader_framebuffer_fetch on i965 on desktop GL (GLES was already > supported) > - GL_EXT_shader_framebuffer_fetch_non_coherent on i965 > - GL_KHR_blend_equation_advanced on radeonsi > - Disk shader cache support for i965 enabled by default > > git tag: mesa-18.1.0 > > https://mesa.freedesktop.org/archive/mesa-18.1.0.tar.gz > MD5: 45e5f4ae434f8e28e11838f6f4de9e32 mesa-18.1.0.tar.gz > SHA1: afaa43310b58154e2fcbc62b5f2b9e30e3cc16ca mesa-18.1.0.tar.gz > SHA256: b1c1dbb42597190503d3abc518b12de880623f097c6cb6c293ecf69ae87e6fbf > mesa-18.1.0.tar.gz > SHA512: 409ba9fc3cfe3668d82e3026d3d12b4ac816bd2732cc1f87302249142530 > 2475ab24a1e19963e1a80dadfadab8e341e71b0ed8c3acc87950378e86ea2e14bbf1 > mesa-18.1.0.tar.gz > PGP: https://mesa.freedesktop.org/archive/mesa-18.1.0.tar.gz.sig > > https://mesa.freedesktop.org/archive/mesa-18.1.0.tar.xz > MD5: 5f4b0d414f2fcef927e465315eb6aa45 mesa-18.1.0.tar.xz > SHA1: 3da4b5f4ae3705c017a8f988f1304be45eed875f mesa-18.1.0.tar.xz > SHA256: c855c5b67ef993b7621f76d8b120769ec0415f1c3616eaff44ef7f7f300aceba > mesa-18.1.0.tar.xz > SHA512: 8b26af2df8b94373cbc339521974cd568c1d4ff4204986ee7b439e4cf3eb > e14d822ea081a7769b68eca9263b7bc6dbca01836b8bb0d6495d2e2614c4e3d601ad > mesa-18.1.0.tar.xz > PGP: https://mesa.freedesktop.org/archive/mesa-18.1.0.tar.xz.sig > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > > > > -- > Stuart Young (aka Cefiar) signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: add news notes to 18.1.0
This is: Reviewed-by: Andres Gomez On Tue, 2018-05-22 at 09:34 +0200, Juan A. Suarez Romero wrote: > CC: Dylan Baker > --- > docs/index.html | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/docs/index.html b/docs/index.html > index 5644ead731a..34418e9bdc8 100644 > --- a/docs/index.html > +++ b/docs/index.html > @@ -16,6 +16,13 @@ > > News > > +May 18, 2018 > + > +Mesa 18.1.0 is released. This is a > +new development release. See the release notes for more information > +about the release. > + > + > May 17, 2018 > > Mesa 18.0.4 is released. -- Br, Andres ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: update release calendar for 18.1 series
On Tue, 2018-05-22 at 09:48 +0200, Juan A. Suarez Romero wrote: > CC: Andres Gomez > CC: Emil Velikov > CC: Dylan Baker > ---spec.arb_texture_multisample.arb_texture_multisample > > As per calendar 18.2.0rc1 starts after the last 18.1.x release, either > we need to update the release calendar for 18.2 series, or extend 18.1 > series. So, why don't you go ahead and extend the 18.1.x series in the calendar and add the TBD ones for the 18.2.x? Either way, this is: Reviewed-by: Andres Gomez -- Br, Andres ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/miptree: Fail gracefully when make_surface returns NULL
On Tue, May 22, 2018 at 10:45:55AM -0700, Ian Romanick wrote:
> On 05/22/2018 09:03 AM, Nanley Chery wrote:
> > On Wed, Jan 03, 2018 at 10:41:43AM -0800, Ian Romanick wrote:
> >> From: Ian Romanick
> >>
> >> Every other caller of make_surface does something sensible when NULL is
> >> returned.
> >>
> >> Signed-off-by: Ian Romanick
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104214
> >
> > I think it'd be helpful to add/use this tag which shows the specific
> > issue out in the wild:
> >
> > Bug: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1760415
> >
> >> Tested-by: Cyril
> >> Cc: "17.3"
> >
> > I think this fixes tag should catch all relevant stable releases:
> >
> > Fixes: 67b53ee4183 "i965: Represent depth surfaces with isl"
>
> Okay... we previously had a case where make_surface would return NULL,
> but we determined that this was because of a problem elsewhere. This
> was fixed by 897c54d522ab9 (loader/dri3: Avoid freeing renderbuffers in
> use).
>
Right.
> Based on this fixes tag, am I correct that another scenario where
> make_surface could fail was added later? Assuming that's correct, is
> this actually the right fix or, as before, is it just papering over
> the real issue?
>
Good question. I did some git blaming and didn't find any modifications
to make_surface after 897c54d522ab9. This patch protects against the OOM
case. Whether or not that is causing the gnome-shell bug, I don't know.
-Nanley
> > With at least the fixes tag, this patch is
> > Reviewed-by: Nanley Chery
> >
> >> ---
> >> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> >> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> >> index ead0c35..0079a08 100644
> >> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> >> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> >> @@ -719,6 +719,9 @@ miptree_create(struct brw_context *brw,
> >> ISL_SURF_USAGE_DEPTH_BIT | ISL_SURF_USAGE_TEXTURE_BIT,
> >> BO_ALLOC_BUSY, 0, NULL);
> >>
> >> + if (mt == NULL)
> >> + return NULL;
> >> +
> >>if (needs_separate_stencil(brw, mt, format) &&
> >>!make_separate_stencil_surface(brw, mt)) {
> >> intel_miptree_release(&mt);
> >> --
> >> 2.9.5
> >>
> >> ___
> >> mesa-dev mailing list
> >> mesa-dev@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3] nv50/ir: add debug options for shader replacement
Changes in v2:
- move "#ifdef DEBUG" from above dumpProgram to above createDumpFilename
Changes in v3:
- Fixed messed up patch description and diff
- Use the checksum of the TGSI instead of the binary if possible
The NV50_PROG_DUMP environment variable specifies a (already created) directory
to dump both shader binaries and tgsi code. The NV50_PROG_REPLACE environment
variable specified a (again, already created) directory that is searched to
find replacement binaries. This is all much like MESA_SHADER_DUMP_PATH and
MESA_SHADER_READ_PATH except using shortened SHA1 checksums instead of program
IDs and chip-specific binaries instead of GLSL.
---
src/gallium/drivers/nouveau/codegen/nv50_ir.cpp | 124
1 file changed, 124 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
index c987da9908..f7fda3a7c6 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
@@ -23,6 +23,10 @@
#include "codegen/nv50_ir.h"
#include "codegen/nv50_ir_target.h"
#include "codegen/nv50_ir_driver.h"
+#ifdef DEBUG
+#include "tgsi/tgsi_dump.h"
+#include "util/mesa-sha1.h"
+#endif
extern "C" {
#include "nouveau_debug.h"
@@ -1161,6 +1165,121 @@ void Program::releaseValue(Value *value)
mem_Symbol.release(value);
}
+#ifdef DEBUG
+static char*
+createDumpFilename(const char *dir, nv50_ir::Program *prog, const char *ext)
+{
+ char* fname = (char*)malloc(strlen(dir)+13+strlen(ext));
+ if (dir[0] && dir[strlen(dir)-1]=='/')
+ strcpy(fname, dir);
+ else
+ sprintf(fname, "%s/", dir);
+
+ unsigned char sha1_bin[20];
+ char sha1_str[41];
+ if (prog->driver->bin.sourceRep == PIPE_SHADER_IR_TGSI) {
+ const tgsi_header* header = (const tgsi_header*)prog->driver->bin.source;
+ unsigned size = (header->HeaderSize + header->BodySize) *
sizeof(tgsi_token);
+ _mesa_sha1_compute(prog->driver->bin.source, size, sha1_bin);
+ } else {
+ _mesa_sha1_compute(prog->code, prog->binSize, sha1_bin);
+ }
+ _mesa_sha1_format(sha1_str, sha1_bin);
+ sha1_str[7] = 0;
+ strcat(fname, sha1_str);
+
+ switch (prog->getType()) {
+ case nv50_ir::Program::TYPE_VERTEX:
+ strcat(fname, ".vs");
+ break;
+ case nv50_ir::Program::TYPE_TESSELLATION_CONTROL:
+ strcat(fname, ".tcs");
+ break;
+ case nv50_ir::Program::TYPE_TESSELLATION_EVAL:
+ strcat(fname, ".tes");
+ break;
+ case nv50_ir::Program::TYPE_GEOMETRY:
+ strcat(fname, ".gs");
+ break;
+ case nv50_ir::Program::TYPE_FRAGMENT:
+ strcat(fname, ".fs");
+ break;
+ case nv50_ir::Program::TYPE_COMPUTE:
+ strcat(fname, ".cs");
+ break;
+ }
+
+ strcat(fname, ext);
+
+ return fname;
+}
+
+static void
+dumpProgram(nv50_ir::Program *prog)
+{
+ const char *dump_dir = debug_get_option("NV50_PROG_DUMP", NULL);
+ if (!dump_dir)
+ return;
+
+ char* fname = createDumpFilename(dump_dir, prog, ".bin");
+
+ FILE *fp = fopen(fname, "wb");
+ if (!fp) {
+ INFO("Failed to dump code of program %p to %s\n", prog, fname);
+ return;
+ }
+
+ fwrite(prog->code, prog->binSize, 1, fp);
+ fclose(fp);
+
+ INFO("Dumped code of program %p to %s\n", prog, fname);
+
+ free(fname);
+
+ if (prog->driver->bin.sourceRep == PIPE_SHADER_IR_TGSI) {
+ char* fname = createDumpFilename(dump_dir, prog, ".tgsi.txt");
+ const tgsi_token *tokens = (const tgsi_token *)prog->driver->bin.source;
+
+ FILE *fp = fopen(fname, "w");
+ tgsi_dump_to_file(tokens, 0, fp);
+ fclose(fp);
+
+ INFO("Dumped tgsi of program %p to %s\n", prog, fname);
+
+ free(fname);
+ }
+}
+
+static void
+replaceProgram(nv50_ir::Program *prog)
+{
+ const nv50_ir::Target* targ = prog->getTarget();
+
+ const char *replace_dir = debug_get_option("NV50_PROG_REPLACE", NULL);
+ if (!replace_dir)
+ return;
+
+ char* fname = createDumpFilename(replace_dir, prog, ".bin");
+
+ FILE *fp = fopen(fname, "rb");
+ if (!fp)
+ return;
+
+ FREE(prog->code);
+ prog->code = (uint32_t*)MALLOC(65536);
+ prog->binSize = fread(prog->code, 1, 65536, fp);
+
+ unsigned maxGPR = targ->getChipset() >= NVISA_GK20A_CHIPSET ? 254 : 62;
+ prog->maxGPR = MIN2(targ->getFileSize(nv50_ir::FILE_GPR), maxGPR);
+
+ fclose(fp);
+
+ INFO("Replaced code of program %p with that from %s\n", prog, fname);
+
+ free(fname);
+}
+#endif
+
} // namespace nv50_ir
@@ -1270,6 +1389,11 @@ nv50_ir_generate_code(struct nv50_ir_prog_info *info)
goto out;
}
+#ifdef DEBUG
+ nv50_ir::dumpProgram(prog);
+ nv50_ir::replaceProgram(prog);
+#endif
+
out:
INFO_DBG(prog->dbgFlags, VERBOSE, "nv50_ir_generate_code: ret = %i\n", ret);
--
2.14.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] docs/releasing: Add note about using a staging branch
On Tuesday, May 22, 2018 10:33:04 AM PDT Andres Gomez wrote: > As commented by Juan, we are already using a staging branch in our own > GitHub clone. If there is no problem in force pushing a branch in the > freedesktop repository, it is OK with me, since we would only be just > pushing there too. > > With the comment and the changes above, this is: > > Reviewed-by: Andres Gomez Force pushing is allowed in the Mesa repository on fdo, and it makes sense for staging branches like that. Feel free. --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
[Mesa-dev] [PATCH 1/2] util/u_math: Implement a logbase2 function for unsigned long
From: Pierre Moreau
Signed-off-by: Karol Herbst
---
src/gallium/auxiliary/util/u_math.h | 55 +
src/util/bitscan.h | 11 ++
2 files changed, 66 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_math.h
b/src/gallium/auxiliary/util/u_math.h
index 46d02978fd6..504d67664b2 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -421,6 +421,23 @@ util_logbase2(unsigned n)
#endif
}
+static inline uint64_t
+util_logbase2_64(uint64_t n)
+{
+#if defined(HAVE___BUILTIN_CLZLL)
+ return ((sizeof(uint64_t) * 8ll - 1ll) - __builtin_clzll(n | 1ll));
+#else
+ uint64_t pos = 0ll;
+ if (n >= 1ll<<32ll) { n >>= 32ll; pos += 32ll; }
+ if (n >= 1ll<<16ll) { n >>= 16ll; pos += 16ll; }
+ if (n >= 1ll<< 8ll) { n >>= 8ll; pos += 8ll; }
+ if (n >= 1ll<< 4ll) { n >>= 4ll; pos += 4ll; }
+ if (n >= 1ll<< 2ll) { n >>= 2ll; pos += 2ll; }
+ if (n >= 1ll<< 1ll) { pos += 1ll; }
+ return pos;
+#endif
+}
+
/**
* Returns the ceiling of log n base 2, and 0 when n == 0. Equivalently,
* returns the smallest x such that n <= 2**x.
@@ -434,6 +451,15 @@ util_logbase2_ceil(unsigned n)
return 1 + util_logbase2(n - 1);
}
+static inline uint64_t
+util_logbase2_ceil64(uint64_t n)
+{
+ if (n <= 1ll)
+ return 0ll;
+
+ return 1ll + util_logbase2_64(n - 1ll);
+}
+
/**
* Returns the smallest power of two >= x
*/
@@ -465,6 +491,35 @@ util_next_power_of_two(unsigned x)
#endif
}
+static inline uint64_t
+util_next_power_of_two64(uint64_t x)
+{
+#if defined(HAVE___BUILTIN_CLZLL)
+ if (x <= 1ll)
+ return 1ll;
+
+ return (1ll << ((sizeof(uint64_t) * 8ll) - __builtin_clzll(x - 1ll)));
+#else
+ uint64_t val = x;
+
+ if (x <= 1ll)
+ return 1ll;
+
+ if (util_is_power_of_two_or_zero64(x))
+ return x;
+
+ val--;
+ val = (val >> 1ll) | val;
+ val = (val >> 2ll) | val;
+ val = (val >> 4ll) | val;
+ val = (val >> 8ll) | val;
+ val = (val >> 16ll) | val;
+ val = (val >> 32ll) | val;
+ val++;
+ return val;
+#endif
+}
+
/**
* Return number of bits set in n.
diff --git a/src/util/bitscan.h b/src/util/bitscan.h
index 5cc75f0beba..310b4ed2e37 100644
--- a/src/util/bitscan.h
+++ b/src/util/bitscan.h
@@ -123,6 +123,17 @@ util_is_power_of_two_or_zero(unsigned v)
return (v & (v - 1)) == 0;
}
+/* Determine if an uint64_t value is a power of two.
+ *
+ * \note
+ * Zero is treated as a power of two.
+ */
+static inline bool
+util_is_power_of_two_or_zero64(uint64_t v)
+{
+ return (v & (v - 1ll)) == 0ll;
+}
+
/* Determine if an unsigned value is a power of two.
*
* \note
--
2.17.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] nv50/ir: Extend ImmediateValue::applyLog2 to 64-bit integers
From: Pierre Moreau
Signed-off-by: Karol Herbst
---
src/gallium/drivers/nouveau/codegen/nv50_ir.cpp | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
index c987da99085..49425b98b91 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
@@ -423,7 +423,10 @@ ImmediateValue::isNegative() const
bool
ImmediateValue::isPow2() const
{
- return util_is_power_of_two_or_zero(reg.data.u32);
+ if (reg.type == TYPE_U64 || reg.type == TYPE_S64)
+ return util_is_power_of_two_or_zero64(reg.data.u64);
+ else
+ return util_is_power_of_two_or_zero(reg.data.u32);
}
void
@@ -440,6 +443,12 @@ ImmediateValue::applyLog2()
case TYPE_U32:
reg.data.u32 = util_logbase2(reg.data.u32);
break;
+ case TYPE_S64:
+ assert(!this->isNegative());
+ // fall through
+ case TYPE_U64:
+ reg.data.u64 = util_logbase2_64(reg.data.u64);
+ break;
case TYPE_F32:
reg.data.f32 = log2f(reg.data.f32);
break;
--
2.17.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/2] gallium: add support for 64 bit util_logbase2_64
Pierre did most of the work, I just rebased those patches on master. Pierre Moreau (2): util/u_math: Implement a logbase2 function for unsigned long nv50/ir: Extend ImmediateValue::applyLog2 to 64-bit integers src/gallium/auxiliary/util/u_math.h | 55 +++ .../drivers/nouveau/codegen/nv50_ir.cpp | 11 +++- src/util/bitscan.h| 11 3 files changed, 76 insertions(+), 1 deletion(-) -- 2.17.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/10] i965: Remove ring switching entirely
Awesome, thanks for doing this, Jason! Patches 1-11 are: Reviewed-by: Kenneth Graunke 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 4.16 039/110] drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk
On Tue, May 22, 2018 at 01:09:07AM -0700, Martin Peres wrote: > Sorry for top-posting, but why is this email on mesa-dev, and not on > intel-gfx? I mean, the latter is for the kernel driver while the former > is the userspace 3d driver, so intel-...@lists.freedesktop.org is > definitely the prefered mailing list for these discussions. My scripts are picking up the following line in the patch: > > Cc: mesa-dev@lists.freedesktop.org That's all. thanks, greg k-h ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 1/3] nvc0: ensure nvc0->bufctx is in effect in nvc0_hw_get_query_resource()
Signed-off-by: Rhys Perry --- src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c b/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c index a420ed4ac0..db5f5092ba 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c @@ -419,6 +419,9 @@ nvc0_hw_get_query_result_resource(struct nvc0_context *nvc0, if (wait && hq->state != NVC0_HW_QUERY_STATE_READY) nvc0_hw_query_fifo_wait(nvc0, q); + nouveau_pushbuf_bufctx(push, nvc0->bufctx); + nouveau_pushbuf_validate(push); + nouveau_pushbuf_space(push, 32, 2, 0); PUSH_REFN (push, hq->bo, NOUVEAU_BO_GART | NOUVEAU_BO_RD); PUSH_REFN (push, buf->bo, buf->domain | NOUVEAU_BO_WR); -- 2.14.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 0/3] nvc0: Various improvements to nvc0_hw_get_query_result_resource
This patch set applies improvements related to the query buffer object functionality of the nvc0 driver. Changes in v3: - Ensure nvc0->bufctx is in effect in get_query_result_resource() instead of setting it as current at the end of nvc0_draw_vbo() - Rebase to master Changes in v2: - Increase space requirement in patch 3 to ensure there is room for fence emission. Rhys Perry (3): nvc0: ensure nvc0->bufctx is in effect in nvc0_hw_get_query_resource() nvc0: rewrite query buffer write macro to output 64-bit predicates nvc0: use a macro to write query result availability to a buffer src/gallium/drivers/nouveau/nvc0/mme/com9097.mme | 136 - src/gallium/drivers/nouveau/nvc0/mme/com9097.mme.h | 98 + src/gallium/drivers/nouveau/nvc0/nvc0_macros.h | 2 + src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c | 162 +++-- src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + 5 files changed, 252 insertions(+), 147 deletions(-) -- 2.14.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 3/3] nvc0: use a macro to write query result availability to a buffer
Both the availability and result paths shared a bit of code so they were
marged.
Signed-off-by: Rhys Perry
---
src/gallium/drivers/nouveau/nvc0/mme/com9097.mme | 45
src/gallium/drivers/nouveau/nvc0/mme/com9097.mme.h | 34 ++
src/gallium/drivers/nouveau/nvc0/nvc0_macros.h | 2 +
src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c | 128 ++---
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 +
5 files changed, 141 insertions(+), 69 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme
b/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme
index 0e5ad66f56..08dbc941ec 100644
--- a/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme
+++ b/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme
@@ -564,6 +564,51 @@ qbw_done:
exit send (extrinsrt 0x0 $r7 0 16 16)
maddrsend 0x44 /* SERIALIZE */
+/* NVC0_3D_MACRO_QUERY_BUFFER_WRITE_AVAIL:
+ *
+ * Like NVC0_3D_MACRO_QUERY_BUFFER_WRITE, this uses the query engine to write
+ * out values.
+ *
+ * arg = write64 ? 1 : 0
+ * parm[0] = desired sequence
+ * parm[1] = actual sequence
+ * parm[2] = LSB of destination address
+ * parm[3] = MSB of destination address
+ */
+.section #mme9097_query_buffer_write_avail
+ parm $r2
+ parm $r3
+ parm $r4
+ parm $r5
+ mov $r6 (sub $r3 $r2)
+ mov $r6 (sbb 0x0 0x0)
+ branz annul $r6 #qbwa_not_avail
+qbwa_avail:
+ mov $r6 0x1
+ bra annul #qbwa_write
+qbwa_not_avail:
+ mov $r6 0x0
+qbwa_write:
+ maddr 0x16c0 /* QUERY_ADDRESS_HIGH */
+ send $r5
+ send $r4
+ send $r6
+ braz $r1 #qbwa_done
+ mov $r7 0x1000
+ send (extrinsrt 0x0 $r7 0 16 16)
+qbwa_high:
+ /* XXX: things seem to mess up if $r6 is replaced with 0x4 in the add */
+ mov $r6 0x4
+ mov $r4 (add $r4 $r6)
+ mov $r5 (adc $r5 0x0)
+ maddr 0x16c0 /* QUERY_ADDRESS_HIGH */
+ send $r5
+ send $r4
+ send 0x0
+qbwa_done:
+ exit send (extrinsrt 0x0 $r7 0 16 16)
+ maddrsend 0x44 /* SERIALIZE */
+
/* NVC0_3D_MACRO_CONSERVATIVE_RASTER_STATE:
*
* This sets basically all the conservative rasterization state. It sets
diff --git a/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme.h
b/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme.h
index 3ebfda47ee..7a8b9b2018 100644
--- a/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme.h
+++ b/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme.h
@@ -380,6 +380,40 @@ uint32_t mme9097_query_buffer_write[] = {
0x00110071,
};
+uint32_t mme9097_query_buffer_write_avail[] = {
+ 0x0201,
+/* 0x0007: qbwa_avail */
+ 0x0301,
+/* 0x0009: qbwa_not_avail */
+/* 0x000a: qbwa_write */
+ 0x0401,
+ 0x0501,
+/* 0x0011: qbwa_high */
+ 0x00049e10,
+ 0x00060610,
+/* 0x0018: qbwa_done */
+ 0xf037,
+ 0x4611,
+ 0x8027,
+ 0x0611,
+ 0x05b00021,
+ 0x2841,
+ 0x2041,
+ 0x3041,
+ 0x00028807,
+ 0x04000711,
+ 0x8401c042,
+ 0x00010611,
+ 0x0001a410,
+ 0x00022d10,
+ 0x05b00021,
+ 0x2841,
+ 0x2041,
+ 0x0041,
+ 0x8401c0c2,
+ 0x00110071,
+};
+
uint32_t mme9097_conservative_raster_state[] = {
0x07400021,
0x0041,
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_macros.h
b/src/gallium/drivers/nouveau/nvc0/nvc0_macros.h
index 7aa0633795..f662ce06b7 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_macros.h
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_macros.h
@@ -39,4 +39,6 @@
#define NVC0_3D_MACRO_CONSERVATIVE_RASTER_STATE
0x3868
+#define NVC0_3D_MACRO_QUERY_BUFFER_WRITE_AVAIL 0x3870
+
#endif /* __NVC0_MACROS_H__ */
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c
index 835742bbc6..a7f895444f 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c
@@ -380,29 +380,11 @@ nvc0_hw_get_query_result_resource(struct nvc0_context
*nvc0,
struct nouveau_pushbuf *push = nvc0->base.pushbuf;
struct nvc0_hw_query *hq = nvc0_hw_query(q);
struct nv04_resource *buf = nv04_resource(resource);
- unsigned qoffset = 0, stride;
bool predicate = false;
- uint32_t arg;
+ uint32_t arg = result_type >= PIPE_QUERY_TYPE_I64 ? 1 : 0;
assert(!hq->funcs || !hq->funcs->get_query_result);
- if (index == -1) {
- /* TODO: Use a macro to write the availability of the query */
- if (hq->state != NVC0_HW_QUERY_STATE_READY)
- nvc0_hw_query_update(nvc0->screen->base.client, q);
- uint32_t ready[2] = {hq->state == NVC0_HW_QUERY_STATE_READY};
- nvc0->base.push_cb(&nvc0->base, buf, offset,
- result_type >= PIPE_QUERY_TYPE_I64 ? 2 : 1,
- ready);
-
- util_range_add(&buf->valid_buffer_range, offset,
- offset + (result_type >= PIPE_QUERY_TYPE_I64 ? 8 : 4));
-
- nvc0_r
[Mesa-dev] [PATCH v3 2/3] nvc0: rewrite query buffer write macro to output 64-bit predicates
Signed-off-by: Rhys Perry
---
src/gallium/drivers/nouveau/nvc0/mme/com9097.mme | 91 --
src/gallium/drivers/nouveau/nvc0/mme/com9097.mme.h | 64 ---
src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c | 81 ++-
3 files changed, 133 insertions(+), 103 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme
b/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme
index 38c2e86843..0e5ad66f56 100644
--- a/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme
+++ b/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme
@@ -494,62 +494,75 @@ daic_runout_check:
/* NVC0_3D_MACRO_QUERY_BUFFER_WRITE:
*
- * This is a combination macro for all of our query buffer object needs.
- * It has the option to clamp results to a configurable amount, as well as
+ * This macro writes out a query's result into a resource.
+ * It has the options to either clamp the result to a configurable amount and
* to write out one or two words.
*
* We use the query engine to write out the values, and expect the query
* address to point to the right place.
*
- * arg = clamp value (0 means unclamped). clamped means just 1 written value.
- * parm[0] = LSB of end value
- * parm[1] = MSB of end value
- * parm[2] = LSB of start value
- * parm[3] = MSB of start value
- * parm[4] = desired sequence
- * parm[5] = actual sequence
- * parm[6] = query high address
+ * Also note that although the result availablility is determined at the start,
+ * the macro only exits if the result is unavailable right before clamping.
+ *
+ * arg = write64 | (clamp<<1)
+ * parm[0] = desired sequence
+ * parm[1] = actual sequence
+ * parm[2] = LSB of end value
+ * parm[3] = MSB of end value
+ * parm[4] = LSB of start value
+ * parm[5] = MSB of start value
+ * parm[6] = clamp value
* parm[7] = query low address
+ * parm[8] = query high address
*/
.section #mme9097_query_buffer_write
+/* determine result availability */
+ parm $r2
+ parm $r3
+ mov $r6 (sub $r3 $r2)
+ mov $r6 (sbb 0x0 0x0)
+/* calculate result and write high into $r3 and low into $r2 */
parm $r2
parm $r3
parm $r4
- parm $r5 maddr 0x16c0 /* QUERY_ADDRESS_HIGH */
- parm $r6
- parm $r7
- mov $r6 (sub $r7 $r6) /* actual - desired */
- mov $r6 (sbb 0x0 0x0) /* if there was underflow, not reached yet */
- parm $r7
- exit braz $r6 #qbw_ready
- parm $r6
-qbw_ready:
+ parm $r5
mov $r2 (sub $r2 $r4)
- braz $r1 #qbw_postclamp
mov $r3 (sbb $r3 $r5)
- branz annul $r3 #qbw_clamp
- mov $r4 (sub $r1 $r2)
- mov $r4 (sbb 0x0 0x0)
- braz annul $r4 #qbw_postclamp
-qbw_clamp:
- mov $r2 $r1
-qbw_postclamp:
- send $r7
- send $r6
+ braz $r6 #qbw_available
+ parm $r4 /* clamp value */
+ exit parm $r7 /* result not available - drain remaining parameters and exit
*/
+ parm $r7
+qbw_available:
+ mov $r6 (extrinsrt 0x0 $r1 1 1 0)
+ braz annul $r6 #qbw_write
+ branz $r3 #qbw_doclamp /* clamp if the high word is set */
+ mov $r7 (sub $r4 $r2)
+ mov $r7 (sbb 0x0 0x0)
+ braz annul $r7 #qbw_write
+qbw_doclamp:
+ mov $r2 $r4
+ mov $r3 0x0
+qbw_write:
+ parm $r5
+ parm $r4 maddr 0x16c0 /* QUERY_ADDRESS_HIGH */
+ send $r4
+ send $r5
send $r2
- branz $r1 #qbw_done
- mov $r4 0x1000
- send (extrinsrt 0x0 $r4 0x0 0x10 0x10)
+ mov $r6 (extrinsrt 0x0 $r1 0 1 0)
+ braz $r6 #qbw_done
+ mov $r7 0x1000
+ send (extrinsrt 0x0 $r7 0 16 16)
+ /* XXX: things seem to mess up if $r6 is replaced with 0x4 in the add */
+ mov $r6 0x4
+ mov $r5 (add $r5 $r6)
+ mov $r4 (adc $r4 0x0)
maddr 0x16c0 /* QUERY_ADDRESS_HIGH */
- mov $r5 0x4
- mov $r6 (add $r6 $r5)
- mov $r7 (adc $r7 0x0)
- send $r7
- send $r6
+ send $r4
+ send $r5
send $r3
qbw_done:
- exit send (extrinsrt 0x0 $r4 0x0 0x10 0x10)
- maddrsend 0x44
+ exit send (extrinsrt 0x0 $r7 0 16 16)
+ maddrsend 0x44 /* SERIALIZE */
/* NVC0_3D_MACRO_CONSERVATIVE_RASTER_STATE:
*
diff --git a/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme.h
b/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme.h
index 49c0891114..3ebfda47ee 100644
--- a/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme.h
+++ b/src/gallium/drivers/nouveau/nvc0/mme/com9097.mme.h
@@ -336,41 +336,47 @@ uint32_t mme9097_draw_arrays_indirect_count[] = {
uint32_t mme9097_query_buffer_write[] = {
0x0201,
0x0301,
-/* 0x000b: qbw_ready */
- 0x0401,
- 0x05b00551,
-/* 0x0012: qbw_clamp */
-/* 0x0013: qbw_postclamp */
- 0x0601,
- 0x0701,
- 0x0005be10,
+ 0x00049e10,
+/* 0x000e: qbw_available */
0x00060610,
-/* 0x0020: qbw_done */
- 0x0701,
- 0xb087,
- 0x0601,
+ 0x0201,
+/* 0x0014: qbw_doclamp */
+/* 0x0016: qbw_write */
+ 0x0301,
+ 0x0401,
+ 0x0501,
0x00051210,
- 0x0001c807,
+/* 0x0026: qbw_done */
0x00075b10,
- 0x00011837,
- 0x00048c10,
- 0x00060410,
-
Re: [Mesa-dev] [PATCH] ac/surface/gfx6: Don't force a tile index for fmask.
Yes. This is the correct fix. Thanks! Reviewed-by: Marek Olšák Marek On Mon, May 21, 2018 at 9:47 AM, Bas Nieuwenhuizen wrote: > The bpe of the fmask often differs from the bpe of the main > surface. On SI that means it has to get a different tile > index. > > addrlib is capable of figuring this out itself, so just pass > -1 instead to let it know that it is not preset. > > Fixes: 9bf3570fed0 "ac/surface/gfx6: compute FMASK together with the color > surface" > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106511 > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106499 > --- > src/amd/common/ac_surface.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c > index d7da9950256..b50157cdb9a 100644 > --- a/src/amd/common/ac_surface.c > +++ b/src/amd/common/ac_surface.c > @@ -868,7 +868,7 @@ static int gfx6_compute_surface(ADDR_HANDLE addrlib, > fin.numSlices = AddrSurfInfoIn.numSlices; > fin.numSamples = AddrSurfInfoIn.numSamples; > fin.numFrags = AddrSurfInfoIn.numFrags; > - fin.tileIndex = AddrSurfInfoOut.tileIndex; > + fin.tileIndex = -1; > fout.pTileInfo = &fmask_tile_info; > > r = AddrComputeFmaskInfo(addrlib, &fin, &fout); > -- > 2.17.0 > > ___ > 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] tgsi/scan: add hw atomic to the list of memory accessing files
Reviewed-by: Marek Olšák Marek On Mon, May 21, 2018 at 2:23 AM, Dave Airlie wrote: > ping? > > On 10 May 2018 at 10:05, Dave Airlie wrote: > > From: Dave Airlie > > > > This fixes 4 out of 5 cases in: > > arb_framebuffer_no_attachments-atomic on cayman. > > --- > > src/gallium/auxiliary/tgsi/tgsi_scan.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.c > b/src/gallium/auxiliary/tgsi/tgsi_scan.c > > index 18488d776e9..aeccb05b56b 100644 > > --- a/src/gallium/auxiliary/tgsi/tgsi_scan.c > > +++ b/src/gallium/auxiliary/tgsi/tgsi_scan.c > > @@ -50,7 +50,8 @@ is_memory_file(unsigned file) > > return file == TGSI_FILE_SAMPLER || > >file == TGSI_FILE_SAMPLER_VIEW || > >file == TGSI_FILE_IMAGE || > > - file == TGSI_FILE_BUFFER; > > + file == TGSI_FILE_BUFFER || > > + file == TGSI_FILE_HW_ATOMIC; > > } > > > > > > -- > > 2.14.3 > > > > ___ > > 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 mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] clover: Cleanup compat code for llvm < 3.9
Signed-off-by: Jan Vesely
---
I've confirmed that simple piglits run on turks(llvm-7) and
carrizo(llvm-6,7). Travis says it builds ok for all supported llvm
versions.
.../clover/llvm/codegen/native.cpp| 7 +-
.../state_trackers/clover/llvm/compat.hpp | 109 +-
.../state_trackers/clover/llvm/invocation.cpp | 25 ++--
3 files changed, 20 insertions(+), 121 deletions(-)
diff --git a/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
b/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
index 4b589ef50c..a6c9ba1f52 100644
--- a/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
+++ b/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
@@ -114,8 +114,7 @@ namespace {
std::unique_ptr tm {
t->createTargetMachine(target.triple, target.cpu, "", {},
-compat::default_reloc_model,
-compat::default_code_model,
+::llvm::None, compat::default_code_model,
::llvm::CodeGenOpt::Default) };
if (!tm)
fail(r_log, build_error(),
@@ -124,10 +123,10 @@ namespace {
::llvm::SmallVector data;
{
- compat::pass_manager pm;
+ ::llvm::legacy::PassManager pm;
::llvm::raw_svector_ostream os { data };
- mod.setDataLayout(compat::get_data_layout(*tm));
+ mod.setDataLayout(tm->createDataLayout());
tm->Options.MCOptions.AsmVerbose =
(ft == TargetMachine::CGFT_AssemblyFile);
diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp
b/src/gallium/state_trackers/clover/llvm/compat.hpp
index 96ba798970..8f2f128048 100644
--- a/src/gallium/state_trackers/clover/llvm/compat.hpp
+++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
@@ -54,15 +54,8 @@
#include
#endif
-#if HAVE_LLVM >= 0x0307
#include
#include
-#else
-#include
-#include
-#include
-#include
-#endif
#include
#include
@@ -71,12 +64,6 @@
namespace clover {
namespace llvm {
namespace compat {
-#if HAVE_LLVM >= 0x0307
- typedef ::llvm::TargetLibraryInfoImpl target_library_info;
-#else
- typedef ::llvm::TargetLibraryInfo target_library_info;
-#endif
-
template
unsigned target_address_space(const T &target, const AS lang_as) {
const auto &map = target.getAddressSpaceMap();
@@ -95,19 +82,6 @@ namespace clover {
const clang::LangStandard::Kind lang_opencl10 =
clang::LangStandard::lang_opencl;
#endif
- inline void
- set_lang_defaults(clang::CompilerInvocation &inv,
- clang::LangOptions &lopts, clang::InputKind ik,
- const ::llvm::Triple &t,
- clang::PreprocessorOptions &ppopts,
- clang::LangStandard::Kind std) {
-#if HAVE_LLVM >= 0x0309
-inv.setLangDefaults(lopts, ik, t, ppopts, std);
-#else
-inv.setLangDefaults(lopts, ik, std);
-#endif
- }
-
inline void
add_link_bitcode_file(clang::CodeGenOptions &opts,
const std::string &path) {
@@ -118,78 +92,8 @@ namespace clover {
F.PropagateAttrs = true;
F.LinkFlags = ::llvm::Linker::Flags::None;
opts.LinkBitcodeFiles.emplace_back(F);
-#elif HAVE_LLVM >= 0x0308
-opts.LinkBitcodeFiles.emplace_back(::llvm::Linker::Flags::None,
path);
-#else
-opts.LinkBitcodeFile = path;
-#endif
- }
-
-#if HAVE_LLVM >= 0x0307
- typedef ::llvm::legacy::PassManager pass_manager;
-#else
- typedef ::llvm::PassManager pass_manager;
-#endif
-
- inline void
- add_data_layout_pass(pass_manager &pm) {
-#if HAVE_LLVM < 0x0307
-pm.add(new ::llvm::DataLayoutPass());
-#endif
- }
-
- inline void
- add_internalize_pass(pass_manager &pm,
- const std::vector &names) {
-#if HAVE_LLVM >= 0x0309
-pm.add(::llvm::createInternalizePass(
- [=](const ::llvm::GlobalValue &gv) {
- return std::find(names.begin(), names.end(),
- gv.getName()) != names.end();
- }));
#else
-pm.add(::llvm::createInternalizePass(std::vector(
- map(std::mem_fn(&std::string::data), names;
-#endif
- }
-
- inline std::unique_ptr< ::llvm::Linker>
- create_linker(::llvm::Module &mod) {
-#if HAVE_LLVM >= 0x0308
-return std::unique_ptr< ::llvm::Linker>(new ::llvm::Linker(mod));
-#else
-return std::unique_ptr< ::llvm::Linker>(new ::llvm::Linker(&mod));
-#endif
- }
-
- inline bool
- link_in_module(::llvm::Linker &linker,
-std::unique_ptr< ::llvm::Module> mod) {
-#if HAVE_LLVM >= 0x0308
-return linker
[Mesa-dev] [PATCH 1/3] clover: Fix build after llvm r332881.
r332881 added an extra parameter to the emit function.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106619
Signed-off-by: Jan Vesely
---
.../state_trackers/clover/llvm/codegen/native.cpp | 3 +--
src/gallium/state_trackers/clover/llvm/compat.hpp | 10 ++
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
b/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
index 409f8ac32f..4b589ef50c 100644
--- a/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
+++ b/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
@@ -126,13 +126,12 @@ namespace {
{
compat::pass_manager pm;
::llvm::raw_svector_ostream os { data };
- compat::raw_ostream_to_emit_file fos(os);
mod.setDataLayout(compat::get_data_layout(*tm));
tm->Options.MCOptions.AsmVerbose =
(ft == TargetMachine::CGFT_AssemblyFile);
- if (tm->addPassesToEmitFile(pm, fos, ft))
+ if (compat::add_passes_to_emit_file(*tm, pm, os, ft))
fail(r_log, build_error(), "TargetMachine can't emit this file");
pm.run(mod);
diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp
b/src/gallium/state_trackers/clover/llvm/compat.hpp
index 2e070b2eef..96ba798970 100644
--- a/src/gallium/state_trackers/clover/llvm/compat.hpp
+++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
@@ -245,6 +245,16 @@ namespace clover {
::llvm::WriteBitcodeToFile(mod, os);
#else
::llvm::WriteBitcodeToFile(&mod, os);
+#endif
+ }
+ template
+ bool add_passes_to_emit_file(TM &tm, PM &pm, OS &os, FT &ft)
+ {
+ compat::raw_ostream_to_emit_file fos(os);
+#if HAVE_LLVM >= 0x0700
+ return tm.addPassesToEmitFile(pm, fos, nullptr, ft);
+#else
+ return tm.addPassesToEmitFile(pm, fos, ft);
#endif
}
}
--
2.17.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] travis: Add clover llvm-6.0 build
Signed-off-by: Jan Vesely
---
.travis.yml | 35 +++
1 file changed, 35 insertions(+)
diff --git a/.travis.yml b/.travis.yml
index e3471d47ac..33dcbcc8da 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -290,6 +290,41 @@ matrix:
- libx11-xcb-dev
- libelf-dev
- libunwind8-dev
+- env:
+# NOTE: Analogous to SWR above, building Clover is quite slow.
+- LABEL="make Gallium ST Clover LLVM-6.0"
+- BUILD=make
+- MAKEFLAGS="-j4"
+- MAKE_CHECK_COMMAND="true"
+- LLVM_VERSION=6.0
+- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
+- OVERRIDE_CC=gcc-4.8
+- OVERRIDE_CXX=g++-4.8
+- DRI_LOADERS="--disable-glx --disable-gbm --disable-egl"
+- DRI_DRIVERS=""
+- GALLIUM_ST="--disable-dri --enable-opencl --enable-opencl-icd
--enable-llvm --disable-xa --disable-nine --disable-xvmc --disable-vdpau
--disable-va --disable-omx-bellagio --disable-gallium-osmesa"
+- GALLIUM_DRIVERS="r600,radeonsi"
+- VULKAN_DRIVERS=""
+- LIBUNWIND_FLAGS="--enable-libunwind"
+ addons:
+apt:
+ sources:
+- llvm-toolchain-trusty-6.0
+# llvm-6 depends on gcc-4.9 which is not in main repo
+- ubuntu-toolchain-r-test
+ packages:
+- libclc-dev
+# From sources above
+- llvm-6.0-dev
+- clang-6.0
+- libclang-6.0-dev
+# Common
+- xz-utils
+- x11proto-xf86vidmode-dev
+- libexpat1-dev
+- libx11-xcb-dev
+- libelf-dev
+- libunwind8-dev
- env:
- LABEL="make Gallium ST Other"
- BUILD=make
--
2.17.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 106619] [OpenCL][llvm-svn]build failure addPassesToEmitFile candidate expects 6 arguments, 3 provided
https://bugs.freedesktop.org/show_bug.cgi?id=106619 --- Comment #1 from Jan Vesely --- Possible fix https://patchwork.freedesktop.org/patch/224857/ -- 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 09/13] i965/tiled_memcpy: inline movntdqa loads in tiled_to_linear
On Mon, Apr 30, 2018 at 4:34 PM, Scott D Phillips
wrote:
> Matt Turner writes:
>
>> On Mon, Apr 30, 2018 at 10:25 AM, Scott D Phillips
>> wrote:
>>> The reference for MOVNTDQA says:
>>>
>>> For WC memory type, the nontemporal hint may be implemented by
>>> loading a temporary internal buffer with the equivalent of an
>>> aligned cache line without filling this data to the cache.
>>> [...] Subsequent MOVNTDQA reads to unread portions of the WC
>>> cache line will receive data from the temporary internal
>>> buffer if data is available.
>>>
>>> This hidden cache line sized temporary buffer can improve the
>>> read performance from wc maps.
>>>
>>> v2: Add mfence at start of tiled_to_linear for streaming loads (Chris)
>>>
>>> Reviewed-by: Chris Wilson
>>
>> I think I understand the mechanics of this change. Let me tell you
>> what I think is going on and you can confirm my understanding.
>>
>> We want to inline a movntdqa-using memcpy function into the tiling
>> functions for performance reasons. Since movntdqa is an SSE4.1
>> instruction, we must split out intel_tiled_memcpy.c into its own
>> convenience library so it can be built with -msse4.1.
>>
>> Because the existing _mesa_streaming_load_memcpy is compiled into its
>> own object file, we can't use it directly (and we might not want to
>> use it directly anyway, since it calls _mm_mfence() we can just do it
>> once at the very end of the calling function). So we implement a
>> simple memcpy with movntdqa capable of handling only 16-bytes or
>> 64-bytes.
>>
>> Somewhat oddly, we pass in _mesa_streaming_load_memcpy (which we
>> cannot inline) and then actually call our simpler memcpy. It's safe to
>> only protect the SSE4.1-using code with #if defined(USE_SSE41) because
>> _mesa_streaming_load_memcpy is only passed if cpu_has_sse4_1 is true
>> (in the next patch).
>>
>> Did I miss anything?
>
> You've got it exactly.
>
>>> ---
>>> src/mesa/drivers/dri/i965/Makefile.am | 7 +++
>>> src/mesa/drivers/dri/i965/Makefile.sources | 6 ++-
>>> src/mesa/drivers/dri/i965/intel_tiled_memcpy.c | 62
>>> ++
>>> src/mesa/drivers/dri/i965/meson.build | 18 ++--
>>> 4 files changed, 88 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/i965/Makefile.am
>>> b/src/mesa/drivers/dri/i965/Makefile.am
>>> index 889d4c68a2b..ff47add93f4 100644
>>> --- a/src/mesa/drivers/dri/i965/Makefile.am
>>> +++ b/src/mesa/drivers/dri/i965/Makefile.am
>>> @@ -92,8 +92,14 @@ libi965_gen11_la_CFLAGS = $(AM_CFLAGS)
>>> -DGEN_VERSIONx10=110
>>>
>>> noinst_LTLIBRARIES = \
>>> libi965_dri.la \
>>> + libintel_tiled_memcpy.la \
>>> $(I965_PERGEN_LIBS)
>>>
>>> +libintel_tiled_memcpy_la_SOURCES = \
>>> + $(intel_tiled_memcpy_FILES)
>>> +libintel_tiled_memcpy_la_CFLAGS = \
>>> + $(AM_CFLAGS) $(SSE41_CFLAGS)
>>> +
>>> libi965_dri_la_SOURCES = \
>>> $(i965_FILES) \
>>> $(i965_oa_GENERATED_FILES)
>>> @@ -104,6 +110,7 @@ libi965_dri_la_LIBADD = \
>>> $(top_builddir)/src/intel/compiler/libintel_compiler.la \
>>> $(top_builddir)/src/intel/blorp/libblorp.la \
>>> $(I965_PERGEN_LIBS) \
>>> + libintel_tiled_memcpy.la
>>> $(LIBDRM_LIBS)
>>>
>>> BUILT_SOURCES = $(i965_oa_GENERATED_FILES)
>>> diff --git a/src/mesa/drivers/dri/i965/Makefile.sources
>>> b/src/mesa/drivers/dri/i965/Makefile.sources
>>> index 5e53d874d88..a15bba50eec 100644
>>> --- a/src/mesa/drivers/dri/i965/Makefile.sources
>>> +++ b/src/mesa/drivers/dri/i965/Makefile.sources
>>> @@ -112,11 +112,13 @@ i965_FILES = \
>>> intel_tex_image.c \
>>> intel_tex_obj.h \
>>> intel_tex_validate.c \
>>> - intel_tiled_memcpy.c \
>>> - intel_tiled_memcpy.h \
>>> intel_upload.c \
>>> libdrm_macros.h
>>>
>>> +intel_tiled_memcpy_FILES = \
>>> + intel_tiled_memcpy.c \
>>> + intel_tiled_memcpy.h
>>> +
>>> i965_gen4_FILES = \
>>> genX_blorp_exec.c \
>>> genX_state_upload.c
>>> diff --git a/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
>>> b/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
>>> index 7c6bde990d6..fac5427d2ed 100644
>>> --- a/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
>>> +++ b/src/mesa/drivers/dri/i965/intel_tiled_memcpy.c
>>> @@ -36,6 +36,10 @@
>>> #include "brw_context.h"
>>> #include "intel_tiled_memcpy.h"
>>>
>>> +#if defined(USE_SSE41)
>>> +#include "main/streaming-load-memcpy.h"
>>> +#include
>>> +#endif
>>> #if defined(__SSSE3__)
>>> #include
>>> #elif defined(__SSE2__)
>>> @@ -213,6 +217,31 @@ rgba8_copy_aligned_src(void *dst, const void *src,
>>> size_t bytes)
>>> return dst;
>>> }
>>>
>>> +#if defined(USE_SSE41)
>>> +static ALWAYS_INLINE void *
>>> +_memcpy_streaming_load(void *dest, const void *src, size_t count)
>>> +{
>>> + if (count == 16) {
>>
>> After inlining and some optimization, the compiler will know for sure
>> what count is, right? Curious i
[Mesa-dev] [Bug 106511] radv: MSAA broken on SI (assertion failure in vkCreateImage)
https://bugs.freedesktop.org/show_bug.cgi?id=106511 Bas Nieuwenhuizen changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- 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] [RFC PATCH] virgl: Always assume that ORIGIN_UPPER_LEFT and PIXEL_CENTER* are supported
Reviewed-by: Gurchetan Singh On Mon, May 21, 2018 at 12:37 AM Gert Wollny wrote: > Am Donnerstag, den 17.05.2018, 12:33 +0200 schrieb Gert Wollny: > > The driver must support at least one of > > > > PIPE_CAP_TGSI_FS_COORD_ORIGIN_UPPER_LEFT > > PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT > > > > and one of > > > > PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_HALF_INTEGER > > PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER > > > > otherwise glsl_to_tgsi will fire an assert. > > > > ORIGIN_UPPER_LEFT is the default convention, and is supported by > > all mesa drivers, hence it seems reasonable to always report the caps > > to be enabled. On gles ORIGIN_LOWER_LEFT is generally not supported, > > so we rely on the caps reported by the host that depend on whether we > > run on an GL or an EGL host. > > > > For PIXEL_CENTER it is completely host driver dependend on what is > > supported, and since we do not report the actual host driver > > capabilities > > it is best to mark both as supported, this is how it works for a GL > > host too. > > > > Fixes: > > dEQP-GLES3.functional.shaders.builtin_variable.fragcoord_xyz > > dEQP-GLES3.functional.shaders.metamorphic.bubblesort_flag.variant_1 > > dEQP-GLES3.functional.shaders.metamorphic.bubblesort_flag.variant_2 > > > > Signed-off-by: Gert Wollny > > --- > > When I return 1 for PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT too, > > the test fail on an r600g gle host. Likewise, when I disable one of > > the two PIXEL_CENTER caps. > > > > However, I send this as an RFC, because there are some of the > > *texture* tests that flip: some start to pass with this patch and > > some start to fail, in total 16 test are fixed with this patch and 15 > > regress on Intel. I have not yet established whether these tests are > > actually unstable. > > After quite some testing I've come to the conclusion that the tests > that flip between Pass and Fail are tests that are generally unstable > when run inside Qemu, so it should be save to apply it. > > Best, > Gert > > > > > thanks for any comments. > > Gert > > > > src/gallium/drivers/virgl/virgl_screen.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/src/gallium/drivers/virgl/virgl_screen.c > > b/src/gallium/drivers/virgl/virgl_screen.c > > index 1ca9e85de7..f4fdc61b14 100644 > > --- a/src/gallium/drivers/virgl/virgl_screen.c > > +++ b/src/gallium/drivers/virgl/virgl_screen.c > > @@ -88,9 +88,10 @@ virgl_get_param(struct pipe_screen *screen, enum > > pipe_cap param) > > case PIPE_CAP_INDEP_BLEND_FUNC: > >return vscreen->caps.caps.v1.bset.indep_blend_func; > > case PIPE_CAP_TGSI_FS_COORD_ORIGIN_UPPER_LEFT: > > - case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT: > > case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_HALF_INTEGER: > > case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER: > > + return 1; > > + case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT: > >return vscreen->caps.caps.v1.bset.fragment_coord_conventions; > > case PIPE_CAP_DEPTH_CLIP_DISABLE: > >return vscreen->caps.caps.v1.bset.depth_clip_disable; > ___ > 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 0/2] st/dri format handling cleanups
On Thu, May 17, 2018 at 6:50 AM, Lucas Stach wrote: > Hi all, > > those 2 patches clean up and align the format handling in the dri state > tracker to how the intel driver implements some details of the interface. > > This is mostly in preparation for etnaviv to support native planar YUV > import without needing any of the R8/RG88 sampler rewrites, as those are > really costly due to some of the Vivante hardware constraints. This isn't > quite ready yet, but I wanted to get those patches out, as those have > some value on their own. Just looking at the diffstat should be motivation > enough to pull them in. > > As this has the potential to break the NV12 import for drivers using the > sampler rewrite (though I think I've covered all cases) I would appreciate > some testing from the Freedreno folks, or whoever cares about this. > radeonsi also supports NV12 with the R8/RG88 split. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeonsi: Track pipe_vertex_buffers for relocs.
Hi Marek, On Tuesday, 22 May 2018 02:09:44 CEST Marek Olšák wrote: > And the old code does exactly the same thing - it avoids duplicate calls > for the same pipe_vertex_buffer, because vertex elements reusing vertex > buffer slots don't have their bit set in first_vb_use_mask, so > add_to_buffer_list is never called for those vertex elements. Ok, now I see. Yes, you are right! Forget the patch and thanks anyhow! best Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/5] egl/wayland: Allow client->server format conversion for PRIME offload.
On Mon, May 21, 2018 at 4:42 PM, Eric Engestrom
wrote:
> On Saturday, 2018-05-19 05:32:41 +0200, Mario Kleiner wrote:
>> Support PRIME render offload between a Wayland server gpu and a Wayland
>> client gpu with different channel ordering for their color formats,
>> e.g., between Intel drivers which currently only support ARGB2101010
>> and XRGB2101010 import/display and nouveau which only supports ABGR2101010
>> rendering and display on nv-50 and later.
>>
>> In the wl_visuals table, we also store for each format an alternate
>> sibling format which stores colors at the same precision, but with
>> different channel ordering, e.g., ARGB2101010 <-> ABGR2101010.
>>
>> If a given client-gpu renderable format is not supported by the server
>> for import, but the alternate format is supported by the server, expose
>> the client-gpu renderable format as a valid EGLConfig to the client. At
>> eglSwapBuffers time, during the blitImage() detiling blit from the client
>> backbuffer to the linear buffer, the client format is converted to the
>> server supported format. As we have to do a copy for PRIME anyway,
>> this channel swizzling conversion comes essentially for free.
>>
>> Note that even if a server gpu in principle does support sampling
>> from the clients native format, this conversion will be a performance
>> advantage if it allows to convert to the servers preferred format
>> for direct scanout, as the Wayland compositor may then be able to
>> directly page-flip a fullscreen client wl_buffer onto the primary
>> plane, or onto a hardware overlay plane, avoiding an extra data copy
>> for desktop composition.
>>
>> Tested so far under Weston with: nouveau single-gpu, Intel single-gpu,
>> AMD single-gpu, "Optimus" Intel server iGPU for display + NVidia
>> client dGPU for rendering.
>>
>> Signed-off-by: Mario Kleiner
>> Cc: Daniel Stone
>> ---
>> src/egl/drivers/dri2/platform_wayland.c | 67
>> -
>> 1 file changed, 58 insertions(+), 9 deletions(-)
>>
>> diff --git a/src/egl/drivers/dri2/platform_wayland.c
>> b/src/egl/drivers/dri2/platform_wayland.c
>> index 89a7f90118..fb364a6233 100644
>> --- a/src/egl/drivers/dri2/platform_wayland.c
>> +++ b/src/egl/drivers/dri2/platform_wayland.c
>> @@ -68,49 +68,50 @@ static const struct dri2_wl_visual {
>> uint32_t wl_drm_format;
>> uint32_t wl_shm_format;
>> int dri_image_format;
>> + int alt_dri_image_format;
>
Thanks for the review.
> A comment here wouldn't hurt, to explain what this "alt" is to someone
> who sees the code after it landed :)
>
Will do, although i usually feel a bit guilty that my patches usually
suffer from over-commenting and essay length commit messages :)
>> int bpp;
>> unsigned int rgba_masks[4];
>> } dri2_wl_visuals[] = {
>> {
>> "XRGB2101010",
>> WL_DRM_FORMAT_XRGB2101010, WL_SHM_FORMAT_XRGB2101010,
>> - __DRI_IMAGE_FORMAT_XRGB2101010, 32,
>> + __DRI_IMAGE_FORMAT_XRGB2101010, __DRI_IMAGE_FORMAT_XBGR2101010, 32,
>> { 0x3ff0, 0x000ffc00, 0x03ff, 0x }
>> },
>> {
>> "ARGB2101010",
>> WL_DRM_FORMAT_ARGB2101010, WL_SHM_FORMAT_ARGB2101010,
>> - __DRI_IMAGE_FORMAT_ARGB2101010, 32,
>> + __DRI_IMAGE_FORMAT_ARGB2101010, __DRI_IMAGE_FORMAT_ABGR2101010, 32,
>> { 0x3ff0, 0x000ffc00, 0x03ff, 0xc000 }
>> },
>> {
>> "XBGR2101010",
>> WL_DRM_FORMAT_XBGR2101010, WL_SHM_FORMAT_XBGR2101010,
>> - __DRI_IMAGE_FORMAT_XBGR2101010, 32,
>> + __DRI_IMAGE_FORMAT_XBGR2101010, __DRI_IMAGE_FORMAT_XRGB2101010, 32,
>> { 0x03ff, 0x000ffc00, 0x3ff0, 0x }
>> },
>> {
>> "ABGR2101010",
>> WL_DRM_FORMAT_ABGR2101010, WL_SHM_FORMAT_ABGR2101010,
>> - __DRI_IMAGE_FORMAT_ABGR2101010, 32,
>> + __DRI_IMAGE_FORMAT_ABGR2101010, __DRI_IMAGE_FORMAT_ARGB2101010, 32,
>> { 0x03ff, 0x000ffc00, 0x3ff0, 0xc000 }
>> },
>> {
>> "XRGB",
>> WL_DRM_FORMAT_XRGB, WL_SHM_FORMAT_XRGB,
>> - __DRI_IMAGE_FORMAT_XRGB, 32,
>> + __DRI_IMAGE_FORMAT_XRGB, __DRI_IMAGE_FORMAT_NONE, 32,
>> { 0x00ff, 0xff00, 0x00ff, 0x }
>> },
>> {
>> "ARGB",
>> WL_DRM_FORMAT_ARGB, WL_SHM_FORMAT_ARGB,
>> - __DRI_IMAGE_FORMAT_ARGB, 32,
>> + __DRI_IMAGE_FORMAT_ARGB, __DRI_IMAGE_FORMAT_NONE, 32,
>> { 0x00ff, 0xff00, 0x00ff, 0xff00 }
>> },
>> {
>> "RGB565",
>> WL_DRM_FORMAT_RGB565, WL_SHM_FORMAT_RGB565,
>> - __DRI_IMAGE_FORMAT_RGB565, 16,
>> + __DRI_IMAGE_FORMAT_RGB565, __DRI_IMAGE_FORMAT_NONE, 16,
>> { 0xf800, 0x07e0, 0x001f, 0x }
>> },
>> };
>> @@ -450,15 +451,23 @@ get_back_bo(struct dri2_egl_surface *dri2_surf)
>> int use_flags;
>> int visual_idx;
>> unsigned int dri_image_format;
>> + unsigned int linear_dri_image_format;
>> uint64_t *modifiers;
>> int num_modifiers;
>>
>> visual_
