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_