[Mesa-dev] [PATCH v3 17/17] Doc/gpu/rfc/i915: i915 DG2 uAPI
Details of the new features getting added as part of DG2 enabling and their implicit impact on the uAPI. v2: improvised the Flat-CCS documentation [Danvet & CQ] Signed-off-by: Ramalingam C cc: Daniel Vetter cc: Matthew Auld cc: Simon Ser cc: Pekka Paalanen Cc: Jordan Justen Cc: Kenneth Graunke Cc: mesa-dev@lists.freedesktop.org Cc: Tony Ye Cc: Slawomir Milczarek --- Documentation/gpu/rfc/i915_dg2.rst | 32 ++ Documentation/gpu/rfc/index.rst| 3 +++ 2 files changed, 35 insertions(+) create mode 100644 Documentation/gpu/rfc/i915_dg2.rst diff --git a/Documentation/gpu/rfc/i915_dg2.rst b/Documentation/gpu/rfc/i915_dg2.rst new file mode 100644 index ..9d28b1812bc7 --- /dev/null +++ b/Documentation/gpu/rfc/i915_dg2.rst @@ -0,0 +1,32 @@ + +I915 DG2 RFC Section + + +Upstream plan += +Plan to upstream the DG2 enabling is: + +* Merge basic HW enabling for DG2 (Still without pciid) +* Merge the 64k support for lmem +* Merge the flat CCS enabling patches +* Add the pciid for DG2 and enable the DG2 in CI + + +64K page support for lmem += +On DG2 hw, local-memory supports minimum GTT page size of 64k only. 4k is not +supported anymore. + +DG2 hw doesn't support the 64k (lmem) and 4k (smem) pages in the same ppgtt +Page table. Refer the struct drm_i915_gem_create_ext for the implication of +handling the 64k page size. + +.. kernel-doc:: include/uapi/drm/i915_drm.h +:functions: drm_i915_gem_create_ext + + +Flat CCS support for lmem += + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_migrate.c +:doc: Flat-CCS - Memory compression for Local memory diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst index 91e93a705230..afb320ed4028 100644 --- a/Documentation/gpu/rfc/index.rst +++ b/Documentation/gpu/rfc/index.rst @@ -20,6 +20,9 @@ host such documentation: i915_gem_lmem.rst +.. toctree:: +i915_dg2.rst + .. toctree:: i915_scheduler.rst -- 2.20.1
[Mesa-dev] [PATCH v3 16/17] drm/i915/Flat-CCS: Document on Flat-CCS memory compression
Documents the Flat-CCS feature and kernel handling required along with
modifiers used.
Signed-off-by: Ramalingam C
cc: Simon Ser
cc: Pekka Paalanen
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: mesa-dev@lists.freedesktop.org
Cc: Tony Ye
Cc: Slawomir Milczarek
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 47 +
1 file changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 0bed01750884..ad5a28da1c6a 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -491,6 +491,53 @@ intel_context_migrate_copy(struct intel_context *ce,
return err;
}
+/**
+ * DOC: Flat-CCS - Memory compression for Local memory
+ *
+ * On Xe-HP and later devices, we use dedicated compression control state (CCS)
+ * stored in local memory for each surface, to support the 3D and media
+ * compression formats.
+ *
+ * The memory required for the CCS of the entire local memory is 1/256 of the
+ * local memory size. So before the kernel boot, the required memory is
reserved
+ * for the CCS data and a secure register will be programmed with the CCS base
+ * address.
+ *
+ * Flat CCS data needs to be cleared when a lmem object is allocated.
+ * And CCS data can be copied in and out of CCS region through
+ * XY_CTRL_SURF_COPY_BLT. CPU can't access the CCS data directly.
+ *
+ * When we exaust the lmem, if the object's placements support smem, then we
can
+ * directly decompress the compressed lmem object into smem and start using it
+ * from smem itself.
+ *
+ * But when we need to swapout the compressed lmem object into a smem region
+ * though objects' placement doesn't support smem, then we copy the lmem
content
+ * as it is into smem region along with ccs data (using XY_CTRL_SURF_COPY_BLT).
+ * When the object is referred, lmem content will be swaped in along with
+ * restoration of the CCS data (using XY_CTRL_SURF_COPY_BLT) at corresponding
+ * location.
+ *
+ *
+ * Flat-CCS Modifiers for different compression formats
+ *
+ *
+ * I915_FORMAT_MOD_F_TILED_DG2_RC_CCS - used to indicate the buffers of Flat
CCS
+ * render compression formats. Though the general layout is same as
+ * I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS, new hashing/compression algorithm is
+ * used. Render compression uses 128 byte compression blocks
+ *
+ * I915_FORMAT_MOD_F_TILED_DG2_MC_CCS -used to indicate the buffers of Flat CCS
+ * media compression formats. Though the general layout is same as
+ * I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS, new hashing/compression algorithm is
+ * used. Media compression uses 256 byte compression blocks.
+ *
+ * I915_FORMAT_MOD_F_TILED_DG2_RC_CCS_CC - used to indicate the buffers of Flat
+ * CCS clear color render compression formats. Unified compression format for
+ * clear color render compression. The genral layout is a tiled layout using
+ * 4Kb tiles i.e Tile4 layout.
+ */
+
static inline u32 *i915_flush_dw(u32 *cmd, u64 dst, u32 flags)
{
/* Mask the 3 LSB to use the PPGTT address space */
--
2.20.1
[Mesa-dev] [PATCH v3 15/17] drm/i915/uapi: document behaviour for DG2 64K support
From: Matthew Auld
On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various reasons, so try to document the new implicit uapi for this.
v2: Fixed suggestions on formatting [Daniel]
Signed-off-by: Matthew Auld
Signed-off-by: Ramalingam C
cc: Simon Ser
cc: Pekka Paalanen
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: mesa-dev@lists.freedesktop.org
Cc: Tony Ye
Cc: Slawomir Milczarek
---
include/uapi/drm/i915_drm.h | 67 ++---
1 file changed, 62 insertions(+), 5 deletions(-)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 914ebd9290e5..89bcf5a77958 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
/**
* When the EXEC_OBJECT_PINNED flag is specified this is populated by
* the user with the GTT offset at which this object will be pinned.
+*
* When the I915_EXEC_NO_RELOC flag is specified this must contain the
* presumed_offset of the object.
+*
* During execbuffer2 the kernel populates it with the value of the
* current GTT offset of the object, for future presumed_offset writes.
+*
+* See struct drm_i915_gem_create_ext for the rules when dealing with
+* alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
+* minimum page sizes, like DG2.
*/
__u64 offset;
@@ -3144,11 +3150,62 @@ struct drm_i915_gem_create_ext {
*
* The (page-aligned) allocated size for the object will be returned.
*
-* Note that for some devices we have might have further minimum
-* page-size restrictions(larger than 4K), like for device local-memory.
-* However in general the final size here should always reflect any
-* rounding up, if for example using the
I915_GEM_CREATE_EXT_MEMORY_REGIONS
-* extension to place the object in device local-memory.
+*
+* **DG2 64K min page size implications:**
+*
+* On discrete platforms, starting from DG2, we have to contend with GTT
+* page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
+* objects. Specifically the hardware only supports 64K or larger GTT
+* page sizes for such memory. The kernel will already ensure that all
+* I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
+* sizes underneath.
+*
+* Note that the returned size here will always reflect any required
+* rounding up done by the kernel, i.e 4K will now become 64K on devices
+* such as DG2.
+*
+* **Special DG2 GTT address alignment requirement:**
+*
+* The GTT alignment will also need be at least 64K for such objects.
+*
+* Note that due to how the hardware implements 64K GTT page support, we
+* have some further complications:
+*
+* 1) The entire PDE(which covers a 2M virtual address range), must
+* contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
+* PDE is forbidden by the hardware.
+*
+* 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
+* objects.
+*
+* To handle the above the kernel implements a memory coloring scheme to
+* prevent userspace from mixing I915_MEMORY_CLASS_DEVICE and
+* I915_MEMORY_CLASS_SYSTEM objects in the same PDE. If the kernel is
+* ever unable to evict the required pages for the given PDE(different
+* color) when inserting the object into the GTT then it will simply
+* fail the request.
+*
+* Since userspace needs to manage the GTT address space themselves,
+* special care is needed to ensure this doesn't happen. The simplest
+* scheme is to simply align and round up all I915_MEMORY_CLASS_DEVICE
+* objects to 2M, which avoids any issues here. At the very least this
+* is likely needed for objects that can be placed in both
+* I915_MEMORY_CLASS_DEVICE and I915_MEMORY_CLASS_SYSTEM, to avoid
+* potential issues when the kernel needs to migrate the object behind
+* the scenes, since that might also involve evicting other objects.
+*
+* **To summarise the GTT rules, on platforms like DG2:**
+*
+* 1) All objects that can be placed in I915_MEMORY_CLASS_DEVICE must
+* have 64K alignment. The kernel will reject this otherwise.
+*
+* 2) All I915_MEMORY_CLASS_DEVICE objects must never be placed in
+* the same PDE with other I915_MEMORY_CLASS_SYSTEM objects. The
+* kernel will reject this otherwise.
+*
+* 3) Objects that can be placed in both I915_MEMORY_CLASS_DEVICE and
[Mesa-dev] [PATCH v3 13/17] uapi/drm/dg2: Format modifier for DG2 unified compression and clear color
From: Matt Roper
DG2 unifies render compression and media compression into a single
format for the first time. The programming and buffer layout is
supposed to match compression on older gen12 platforms, but the
actual compression algorithm is different from any previous platform; as
such, we need a new framebuffer modifier to represent buffers in this
format, but otherwise we can re-use the existing gen12 compression driver
logic.
DG2 clear color render compression uses Tile4 layout. Therefore, we need
to define a new format modifier for uAPI to support clear color rendering.
v2: Rebased on new format modifier check [Ram]
Signed-off-by: Matt Roper
Signed-off-by: Mika Kahola (v2)
Signed-off-by: Juha-Pekka Heikkilä
Signed-off-by: Ramalingam C
cc: Simon Ser
Cc: Pekka Paalanen
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: mesa-dev@lists.freedesktop.org
Cc: Tony Ye
Cc: Slawomir Milczarek
Acked-by: Simon Ser
---
drivers/gpu/drm/i915/display/intel_fb.c | 43 +++
.../drm/i915/display/skl_universal_plane.c| 29 -
include/uapi/drm/drm_fourcc.h | 30 +
3 files changed, 101 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index 562d5244688d..484ae1fd0e94 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -106,6 +106,21 @@ static const struct drm_format_info gen12_ccs_cc_formats[]
= {
.hsub = 1, .vsub = 1, .has_alpha = true },
};
+static const struct drm_format_info gen12_flat_ccs_cc_formats[] = {
+ { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2,
+ .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = { 1, 1 },
+ .hsub = 1, .vsub = 1, },
+ { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2,
+ .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = { 1, 1 },
+ .hsub = 1, .vsub = 1, },
+ { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2,
+ .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = { 1, 1 },
+ .hsub = 1, .vsub = 1, .has_alpha = true },
+ { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2,
+ .char_per_block = { 4, 0 }, .block_w = { 1, 2 }, .block_h = { 1, 1 },
+ .hsub = 1, .vsub = 1, .has_alpha = true },
+};
+
struct intel_modifier_desc {
u64 modifier;
struct {
@@ -166,6 +181,27 @@ static const struct intel_modifier_desc intel_modifiers[]
= {
.ccs.packed_aux_planes = BIT(1),
FORMAT_OVERRIDE(gen12_ccs_cc_formats),
+ }, {
+ .modifier = I915_FORMAT_MOD_4_TILED_DG2_RC_CCS,
+ .display_ver = { 12, 13 },
+ .tiling = I915_TILING_NONE,
+
+ .ccs.type = INTEL_CCS_RC,
+ }, {
+ .modifier = I915_FORMAT_MOD_4_TILED_DG2_MC_CCS,
+ .display_ver = { 12, 13 },
+ .tiling = I915_TILING_NONE,
+
+ .ccs.type = INTEL_CCS_MC,
+ }, {
+ .modifier = I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC,
+ .display_ver = { 12, 13 },
+ .tiling = I915_TILING_NONE,
+
+ .ccs.type = INTEL_CCS_RC_CC,
+ .ccs.cc_planes = BIT(1),
+
+ FORMAT_OVERRIDE(gen12_flat_ccs_cc_formats),
}, {
.modifier = I915_FORMAT_MOD_Yf_TILED_CCS,
.display_ver = { 9, 11 },
@@ -582,6 +618,9 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb,
int color_plane)
return 128;
else
return 512;
+ case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS:
+ case I915_FORMAT_MOD_4_TILED_DG2_MC_CCS:
+ case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC:
case I915_FORMAT_MOD_4_TILED:
/*
* Each 4K tile consists of 64B(8*8) subtiles, with
@@ -759,6 +798,10 @@ unsigned int intel_surf_alignment(const struct
drm_framebuffer *fb,
case I915_FORMAT_MOD_4_TILED:
case I915_FORMAT_MOD_Yf_TILED:
return 1 * 1024 * 1024;
+ case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS:
+ case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC:
+ case I915_FORMAT_MOD_4_TILED_DG2_MC_CCS:
+ return 16 * 1024;
default:
MISSING_CASE(fb->modifier);
return 0;
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index aeca96925feb..136b3f74a290 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -753,6 +753,16 @@ static u32 skl_plane_ctl_tiling(u64 fb_modifier)
return PLANE_CTL_TILED_Y;
case I915_FORMAT_MOD_4_TILED:
return PLANE_CTL_TILED_4;
+ case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS:
+ return
[Mesa-dev] [PATCH v3 12/17] drm/i915/dg2: Tile 4 plane format support
From: Stanislav Lisovskiy
TileF(Tile4 in bspec) format is 4K tile organized into
64B subtiles with same basic shape as for legacy TileY
which will be supported by Display13.
v2: - Fixed wrong case condition(Jani Nikula)
- Increased I915_FORMAT_MOD_F_TILED up to 12(Imre Deak)
v3: - s/I915_TILING_F/TILING_4/g
- s/I915_FORMAT_MOD_F_TILED/I915_FORMAT_MOD_4_TILED/g
- Removed unneeded fencing code
v4: - Rebased, fixed merge conflict with new table-oriented
format modifier checking(Stan)
- Replaced the rest of "Tile F" mentions to "Tile 4"(Stan)
v5: - Fixed the has_4tile addition (Ram)
Cc: Imre Deak
Cc: Matt Roper
Cc: Maarten Lankhorst
cc: Simon Ser
cc: Pekka Paalanen
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: mesa-dev@lists.freedesktop.org
Cc: Tony Ye
Cc: Slawomir Milczarek
Signed-off-by: Stanislav Lisovskiy
Signed-off-by: Matt Roper
Signed-off-by: Juha-Pekka Heikkilä
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/display/intel_display.c | 1 +
drivers/gpu/drm/i915/display/intel_fb.c | 11 ++
drivers/gpu/drm/i915/display/intel_fbc.c | 1 +
.../drm/i915/display/intel_plane_initial.c| 1 +
.../drm/i915/display/skl_universal_plane.c| 20 +++
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/i915_pci.c | 1 +
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_device_info.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 1 +
include/uapi/drm/drm_fourcc.h | 8
11 files changed, 41 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 79cd158503b3..9b3913d73213 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7755,6 +7755,7 @@ static int intel_atomic_check_async(struct
intel_atomic_state *state)
case I915_FORMAT_MOD_X_TILED:
case I915_FORMAT_MOD_Y_TILED:
case I915_FORMAT_MOD_Yf_TILED:
+ case I915_FORMAT_MOD_4_TILED:
break;
default:
drm_dbg_kms(&i915->drm,
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index 9ff52dde1683..562d5244688d 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -188,6 +188,10 @@ static const struct intel_modifier_desc intel_modifiers[]
= {
.modifier = I915_FORMAT_MOD_Yf_TILED,
.display_ver = { 9, 11 },
.tiling = I915_TILING_NONE,
+ }, {
+ .modifier = I915_FORMAT_MOD_4_TILED,
+ .display_ver = { 12, 13 },
+ .tiling = I915_TILING_NONE,
}, {
.modifier = I915_FORMAT_MOD_Y_TILED,
.display_ver = { 9, 13 },
@@ -578,6 +582,12 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb,
int color_plane)
return 128;
else
return 512;
+ case I915_FORMAT_MOD_4_TILED:
+ /*
+* Each 4K tile consists of 64B(8*8) subtiles, with
+* same shape as Y Tile(i.e 4*16B OWords)
+*/
+ return 128;
case I915_FORMAT_MOD_Y_TILED_CCS:
if (intel_fb_is_ccs_aux_plane(fb, color_plane))
return 128;
@@ -746,6 +756,7 @@ unsigned int intel_surf_alignment(const struct
drm_framebuffer *fb,
case I915_FORMAT_MOD_Y_TILED_CCS:
case I915_FORMAT_MOD_Yf_TILED_CCS:
case I915_FORMAT_MOD_Y_TILED:
+ case I915_FORMAT_MOD_4_TILED:
case I915_FORMAT_MOD_Yf_TILED:
return 1 * 1024 * 1024;
default:
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 1f66de77a6b1..f079a771f802 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -747,6 +747,7 @@ static bool tiling_is_valid(struct drm_i915_private
*dev_priv,
case DRM_FORMAT_MOD_LINEAR:
case I915_FORMAT_MOD_Y_TILED:
case I915_FORMAT_MOD_Yf_TILED:
+ case I915_FORMAT_MOD_4_TILED:
return DISPLAY_VER(dev_priv) >= 9;
case I915_FORMAT_MOD_X_TILED:
return true;
diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c
b/drivers/gpu/drm/i915/display/intel_plane_initial.c
index dcd698a02da2..d80855ee9b96 100644
--- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
+++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
@@ -125,6 +125,7 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
case DRM_FORMAT_MOD_LINEAR:
case I915_FORMAT_MOD_X_TILED:
case I915_FORMAT_MOD_Y_TILED:
+ case I915_FORMAT_MOD_4_TILED:
break;
defa
[Mesa-dev] [ANNOUNCE] mesa 21.3.0-rc3
Hello everyone, The third release candidate is now available, containing again mostly zink fixes, and a handful of patches for everything else. Please test it and report any issue here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/new Issues that should block the release of 21.3.0 should be added to the corresponding milestone: https://gitlab.freedesktop.org/mesa/mesa/-/milestones/27 Cheers, Eric --- Alyssa Rosenzweig (7): panfrost: Detect implementations support AFBC panfrost,panvk: Use dev->has_afbc instead of quirks panfrost: Fix gl_FragColor lowering panfrost: Workaround ISSUE_TSIX_2033 panfrost: Add internal afbc_formats panfrost: Decompress for incompatible AFBC formats panfrost: Enable AFBC on v7 Bas Nieuwenhuizen (1): radv: Add bufferDeviceAddressMultiDevice support. Boris Brezillon (1): vulkan: Fix entrypoint generation when compiling for x86 with MSVC Eric Engestrom (2): .pick_status.json: Update to 4856586ac605e89ee6c128b1a190f000311b49ba VERSION: bump for 21.3.0-rc3 Iago Toral Quiroga (1): broadcom/compiler: fix assert that current instruction must be in current block Lionel Landwerlin (2): vulkan/wsi/wayland: don't expose surface formats not fully supported anv: fix push constant lowering with bindless shaders Marek Olšák (1): st/mesa: don't crash when draw indirect buffer has no storage Michael Tang (1): microsoft/spirv_to_dxil: turn sysvals into input varyings Mike Blumenkrantz (15): zink: clear descriptor refs on buffer replacement zink: assert compute descriptor key is valid before hashing it zink: don't update lazy descriptor states in hybrid mode zink: move push descriptor updating into lazy-only codepath zink: add an early return for zink_descriptors_update_lazy_masked() zink: move last of lazy descriptor state updating back to lazy-only code zink: detect prim type more accurately for tess/gs lines zink: don't break early when applying fb clears zink: only reset zink_resource::so_valid on buffer rebind zink: don't check rebind count outside of buffer/image rebind function zink: stop exporting PIPE_SHADER_CAP_FP16_DERIVATIVES zink: don't add dynamic vertex pipeline states if no attribs are used zink: fix gl_SampleMaskIn spirv generation zink: more accurately update samplemask for fs shader keys nir/lower_samplers_as_deref: rewrite more image intrinsics Samuel Pitoiset (4): aco: fix loading 64-bit inputs with fragment shaders radv: re-emit prolog inputs when the nontrivial divisors state changed radv: fix build errors with Android aco: only load streamout buffers if streamout is enabled Tapani Pälli (1): iris: clear bos_written when resetting a batch Thomas Wagner (1): util: use anonymous file for memory fd creation Vinson Lee (1): radv: Fix memory leak on error path. git tag: mesa-21.3.0-rc3 https://mesa.freedesktop.org/archive/mesa-21.3.0-rc3.tar.xz SHA256: bc426790d936f27624c1e485216e228e89c4b3809135798573db260070622386 mesa-21.3.0-rc3.tar.xz SHA512: 14c3cdf2085077db3ec6d7e7b66304fccdaf441dfd64cc085d6d83960fcbdaa18a48d8f6bcdc096def06b6d389f51c1a5cb0a6793a236d668e22c592bc8b2e4c mesa-21.3.0-rc3.tar.xz PGP: https://mesa.freedesktop.org/archive/mesa-21.3.0-rc3.tar.xz.sig signature.asc Description: PGP signature
[Mesa-dev] Mesa Querying Devices Filter
To whom it may concern, I am attempting to use Mesa with EGL for a project and I have run into an issue when initializing a device. My setup uses a surfaceless platform with swrast as the gallium driver. When I query for devices to initialize (using eglQueryDevices), the first device listed is the driver for my GPU (nouveau) and the other devices are the devices I want to initialize (swrast, swr, etc). My project currently loops through all possible devices and initializes each one. Once one is initialized properly, the program continues. I was wondering if there is a way to filter out devices (like drivers for GPU). This would make the output of my program more readable and also save time by not initializing devices that will not work. Also as a side note, why does Mesa query for my GPU drivers in the first place? The only driver I specify to use is swrast and I am not sure why my GPU driver is being found. Best Regards, Stephen Crowell
