[Intel-gfx] [ANNOUNCE] xf86-video-intel 2.21.1
Release 2.21.1 (2013-02-10) === A fix for a potential GPU hang on 945gm (GMA3100) and earlier chipsets, along with backporting SNA to the packages found in stable distributions like Debian 6.0 (Squeeze). * Cleanup compilation warnings from deblint, thanks to Paul Menzel * Minor build improvements by Damien Lespiau. * Disable generating span geometry for non-rectilinear spans on gen4 in order to work around and prevent one class of render corruption. * Prevent cache thrashing and severe performance degradation on LLC machines for streaming texture updates. However, note the effect was only observed on just one particular laptop. * Fix alignment of subsurface proxies for old chipsets. https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel * Repair build against Xorg-1.6 and contemporary packages. Complete list of changes since 2.21.0 - Chris Wilson (36): sna: Do not add the INPLACE hint if we have the ASYNC hint set sna: Drop bogus refcnt assertion during kgem_bo_retire() sna/gen4: Disable non-rectilinear GPU span compositing sna/gen4: Remove old single-thread SF w/a NEWS: Trivial typo s/utilile/utilise/ man: Fix a typo s/debuging/debugging/ intel: add more ValleyView PCI IDs sna: ValleyView uses the same scanline registers as SandyBridge test: Add a very basic blt benchmark sna: Tidy buffer allocation size assertions xvmc: Add the complementary XCB_CFLAGS configure: XvMC support is optional, so make failure to find xcb non-fatal sna: Make sure we always replace io buffers before inserting into the cache sna: Relax the buffer size assertion to only be larger than required sna: Handle mapped buffer allocation failure for LLC sna: Correctly handle failure to CPU map a new allocation sna: Flush our caches if we fail to mmap an object sna: Free the handle after pwrite buffer allocation failure intel: Becareful not to match UMS against future generations sna: Fallback to non-LLC paths after an allocation failure for an LLC buffer sna: Correctly align used buffers to the following page boundary sna: Only try the SRC fixup into the buffer if it is CPU mapped sna: Allow inplace uploads to utilise GTT on LLC machines sna: Force GTT readback if the GPU is wedged sna: Also assert that the GPU is not wedged before continuing a batch sna: Fixup an invalid assertion sna: Remove the bogus assertions on buffer domains sna/gen4: Split the have_render flag in separate prefer_gpu hints sna: Force the fallback path for unaccelerated randr damage sna/gen6: Use GT2 settings for both GT2 and GT2+ sna: Randomly perturb 'wedged' to hunt for faults sna: Promote to GPU is only partially damaged on the CPU but busy on the GPU sna: Fix alignment of the base of partial buffers for pre-G33 chipsets sna: Backport to squeeze - Xorg-1.6, pixman-0.16, libdrm-2.4.21 configure: Fix typo in checking for libdrm_intel sna: Reorder some includes so that compat-api.h comes after the headers it wraps Damien Lespiau (3): build: Make autoreconf honour ACLOCAL_FLAGS build: Use $(AM_V_GEN) to silence the assembly of gen programs build: Make generation of gen code depend on intel-gen4asm Paul Menzel (3): configure.ac: Do not include `xext` and `xfixes` in `XVMCLIB` NEWS: Fix a typo: a*n* inadvertent configure.ac: Split out XCB libraries from `XVMCLIB` into `XCB` git tag: 2.21.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.21.1.tar.bz2 MD5: c9901fc73ce9ff74a079d4c6b4b4a43d xf86-video-intel-2.21.1.tar.bz2 SHA1: fd5984868244962c9b0e40605987d2bdeb1fcf27 xf86-video-intel-2.21.1.tar.bz2 SHA256: 9145ac8a6df09cc35cd2322d09e0cf0c3b2ede701263b9a64581a7a55db7dbfc xf86-video-intel-2.21.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.21.1.tar.gz MD5: 1bed249ba34e19c61b7c7eefcfcda407 xf86-video-intel-2.21.1.tar.gz SHA1: ddb95054374189c97195658a24398cc7b42f99a9 xf86-video-intel-2.21.1.tar.gz SHA256: 8c0809fef924e5a509b30e9b75d430469143e0a13b904acc1a7af12dc42c783e xf86-video-intel-2.21.1.tar.gz -- Chris Wilson, Intel Open Source Technology Centre signature.asc Description: Digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [ANNOUNCE] xf86-video-intel 2.21.2
Release 2.21.2 (2013-02-10) === Pass the brown paper bags, I need half a dozen or so. That seemingly innocuous build fix with xorg-1.13 happned to have the little side-effect of breaking glyph rendering with xorg-1.12 and older on 64-bit machines. Chris Wilson (4): 2.21.1 release NEWS: fix bug url sna: Restore glyphs with xorg-1.12 2.21.2 release git tag: 2.21.2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.21.2.tar.bz2 MD5: 8711750cea7e89f967f192ba30546541 xf86-video-intel-2.21.2.tar.bz2 SHA1: 42f65d7ac9a8cb27b16e134533cc11d2c366451d xf86-video-intel-2.21.2.tar.bz2 SHA256: 2e6890ecacc715caa5459581b00b63152e08646ea1b76330bf79b996a139d850 xf86-video-intel-2.21.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.21.2.tar.gz MD5: 0cd32ed372c32461da566bd66b0d353f xf86-video-intel-2.21.2.tar.gz SHA1: dff3a06c1008ca5d504b2ec9b562dc2fb60cad8e xf86-video-intel-2.21.2.tar.gz SHA256: 0e3801797418fe4f63de742037299cba1233bc03fa34fbc4ac06d0d19ab2c412 xf86-video-intel-2.21.2.tar.gz -- Chris Wilson, Intel Open Source Technology Centre signature.asc Description: Digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] intel_chipset: Merge igt chipsets
IGT is newer and arguably better. This change doesn't completely merge the files because it's a bit simpler if we move the I9XX macro over to IGT, and don't move over a few macros from IGT that libdrm doesn't care about. The advantage is being able to easily synchronize between the two definitions. It has been discussed, and would seem even easier if IGT simply used the libdrm header files, however since we want to keep IGT as isolated as possible, and many tests don't rely on libdrm, this isn't a good idea. This patch has been sitting around on an internal tree for a while, but because Jesse recently pushed VLV ID updates it painfully made me realize that I should probably try to upstream it sooner rather than later. Cc: Jesse Barnes jbar...@virtuousgeek.org Signed-off-by: Ben Widawsky b...@bwidawsk.net --- intel/intel_chipset.h | 176 +- 1 file changed, 101 insertions(+), 75 deletions(-) diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h index ebec2f8..3123a90 100644 --- a/intel/intel_chipset.h +++ b/intel/intel_chipset.h @@ -28,6 +28,48 @@ #ifndef _INTEL_CHIPSET_H #define _INTEL_CHIPSET_H +#define PCI_CHIP_I810 0x7121 +#define PCI_CHIP_I810_DC1000x7123 +#define PCI_CHIP_I810_E0x7125 +#define PCI_CHIP_I815 0x1132 + +#define PCI_CHIP_I830_M0x3577 +#define PCI_CHIP_845_G 0x2562 +#define PCI_CHIP_I855_GM 0x3582 +#define PCI_CHIP_I865_G0x2572 + +#define PCI_CHIP_I915_G0x2582 +#define PCI_CHIP_E7221_G 0x258A +#define PCI_CHIP_I915_GM 0x2592 +#define PCI_CHIP_I945_G0x2772 +#define PCI_CHIP_I945_GM 0x27A2 +#define PCI_CHIP_I945_GME 0x27AE + +#define PCI_CHIP_Q35_G 0x29B2 +#define PCI_CHIP_G33_G 0x29C2 +#define PCI_CHIP_Q33_G 0x29D2 + +#define PCI_CHIP_IGD_GM0xA011 +#define PCI_CHIP_IGD_G 0xA001 + +#define IS_IGDGM(devid)(devid == PCI_CHIP_IGD_GM) +#define IS_IGDG(devid) (devid == PCI_CHIP_IGD_G) +#define IS_IGD(devid) (IS_IGDG(devid) || IS_IGDGM(devid)) + +#define PCI_CHIP_I965_G0x29A2 +#define PCI_CHIP_I965_Q0x2992 +#define PCI_CHIP_I965_G_1 0x2982 +#define PCI_CHIP_I946_GZ 0x2972 +#define PCI_CHIP_I965_GM0x2A02 +#define PCI_CHIP_I965_GME 0x2A12 + +#define PCI_CHIP_GM45_GM0x2A42 + +#define PCI_CHIP_IGD_E_G0x2E02 +#define PCI_CHIP_Q45_G 0x2E12 +#define PCI_CHIP_G45_G 0x2E22 +#define PCI_CHIP_G41_G 0x2E32 + #define PCI_CHIP_ILD_G 0x0042 #define PCI_CHIP_ILM_G 0x0046 @@ -83,96 +125,87 @@ #define PCI_CHIP_HASWELL_CRW_S_GT2 0x0D2A #define PCI_CHIP_HASWELL_CRW_S_GT2_PLUS 0x0D3A -#define PCI_CHIP_VALLEYVIEW_PO 0x0f30 /* power on board */ +#define PCI_CHIP_VALLEYVIEW_PO 0x0f30 /* VLV PO board */ #define PCI_CHIP_VALLEYVIEW_1 0x0f31 #define PCI_CHIP_VALLEYVIEW_2 0x0f32 #define PCI_CHIP_VALLEYVIEW_3 0x0f33 -#define IS_830(dev) (dev == 0x3577) -#define IS_845(dev) (dev == 0x2562) -#define IS_85X(dev) (dev == 0x3582) -#define IS_865(dev) (dev == 0x2572) +#define IS_MOBILE(devid) (devid == PCI_CHIP_I855_GM || \ +devid == PCI_CHIP_I915_GM || \ +devid == PCI_CHIP_I945_GM || \ +devid == PCI_CHIP_I945_GME || \ +devid == PCI_CHIP_I965_GM || \ +devid == PCI_CHIP_I965_GME || \ +devid == PCI_CHIP_GM45_GM || IS_IGD(devid) || \ +devid == PCI_CHIP_IVYBRIDGE_M_GT1 || \ +devid == PCI_CHIP_IVYBRIDGE_M_GT2) -#define IS_GEN2(dev) (IS_830(dev) || \ - IS_845(dev) ||\ - IS_85X(dev) ||\ - IS_865(dev)) +#define IS_G45(devid) (devid == PCI_CHIP_IGD_E_G || \ + devid == PCI_CHIP_Q45_G || \ + devid == PCI_CHIP_G45_G || \ + devid == PCI_CHIP_G41_G) +#define IS_GM45(devid) (devid == PCI_CHIP_GM45_GM) +#define IS_G4X(devid) (IS_G45(devid) || IS_GM45(devid)) -#define IS_915G(dev) (dev == 0x2582 || \ - dev == 0x258a) -#define IS_915GM(dev) (dev == 0x2592) -#define IS_945G(dev) (dev == 0x2772) -#define IS_945GM(dev) (dev == 0x27A2 ||\ -dev == 0x27AE) +#define IS_ILD(devid)
Re: [Intel-gfx] [PATCH] drm/i915: After hibernation, discard the unbound list
On Thu, Feb 07, 2013 at 10:27:47AM +, Chris Wilson wrote:
The unbound list is an optimisation to track objects that have been
evicted from the GTT but remain untouched by the CPU. After hibernation,
all memory is in the CPU domain (having been restored from a disk image)
and so we need to restore the domain tracking upon the objects. However,
for the unbound list we can simply discard those objects and lazily wait
for them to be reused.
v2: Perform the unbound discard explicitly during thawing after
hibernation.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9069e71..f5ccb3d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -592,6 +592,30 @@ static int __i915_drm_thaw(struct drm_device *dev)
return error;
}
+static void i915_gem_discard_unbound(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_i915_gem_object *obj, *next;
+
+ /* After hibernation all memory is in the CPU domain and so we need
+ * to restore our domain tracking. However, the unbound list is
+ * merely an optimisation to track memory that has been evicted from
+ * the GTT but remains in the GTT domain. After hibernation, that
+ * is no longer the case and we can trim the unbound list.
+ */
+ list_for_each_entry_safe(obj, next,
+ dev_priv-mm.unbound_list, gtt_list) {
+ obj-base.read_domains = I915_GEM_DOMAIN_CPU;
+ obj-base.write_domain = I915_GEM_DOMAIN_CPU;
+ if (i915_gem_object_put_pages(obj)) {
+ /* Abandon hope all ye who enter here */
+ obj-base.read_domains = I915_GEM_DOMAIN_GTT;
+ obj-base.write_domain = I915_GEM_DOMAIN_GTT;
+ /* Will be clflushed during restore_gtt_mappings */
+ }
+ }
+}
+
I'm confused by how you're going about this. To reorder what you said,
if an object is on the unbound list the GPU is done with it, and it may
require clflushing if on a non-LLC system.
Then a hibernate comes along. Almost certainly the PM subsystem would
have to invalidate all the caches before moving the image to disk.
Assuming the above is true:
First question, why do you want to i915_gem_object_put_pages(). This
would seem to do a bunch of unnecessary stuff (primarily setting pages
as dirty when they need not be).
and second, why do you set I915_GEM_DOMAIN_GTT when put_pages fails?
Is that just a hack to get the clflush?
I think if you can convince me why we need to clflush after resume, I'd
be happy.
static int i915_drm_thaw(struct drm_device *dev)
{
int error = 0;
@@ -600,6 +624,7 @@ static int i915_drm_thaw(struct drm_device *dev)
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
mutex_lock(dev-struct_mutex);
+ i915_gem_discard_unbound(dev);
i915_gem_restore_gtt_mappings(dev);
mutex_unlock(dev-struct_mutex);
}
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: After hibernation, discard the unbound list
On Sun, Feb 10, 2013 at 11:04:17AM -0800, Ben Widawsky wrote: I'm confused by how you're going about this. To reorder what you said, if an object is on the unbound list the GPU is done with it, and it may require clflushing if on a non-LLC system. Right, the objects on the unbound list are explicitly not in the CPU domain and so we believe we can skip the clflush next time we try and use them on the GPU. Then a hibernate comes along. Almost certainly the PM subsystem would have to invalidate all the caches before moving the image to disk. s/PM/we/ The PM subsystem just concerns itself with moving pages from ram to disk and back. Assuming the above is true: First question, why do you want to i915_gem_object_put_pages(). This would seem to do a bunch of unnecessary stuff (primarily setting pages as dirty when they need not be). Not unnecessary. Even after hibernation since we need to keep the VM bookkeeping happy and working in our favour. and second, why do you set I915_GEM_DOMAIN_GTT when put_pages fails? Is that just a hack to get the clflush? Right. So that our invariants about the unbound list hold. I think if you can convince me why we need to clflush after resume, I'd be happy. Because moving pages around trashed the CPU caches and upset our domain tracking. The clflush is then required to move the object back into the domain we believe it to be. Otherwise we end up with the GPU reading stale data and hanging. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Read the Base of Stolen Memory for 915gm
Reading the cspec pays dividends once again, as I found the 'Base of
Stolen Memory' config register so that we can skip the fragile
computation from Top of Usable Draw and use the real value provided by
the BIOS.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem_stolen.c |9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 130d1db..7f1735c 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -72,13 +72,10 @@ static unsigned long i915_stolen_to_physical(struct
drm_device *dev)
} else if (INTEL_INFO(dev)-gen 3 || IS_G33(dev)) {
/* Read Graphics Base of Stolen Memory directly */
pci_read_config_dword(pdev, 0xA4, base);
-#if 0
} else if (IS_GEN3(dev)) {
- u8 val;
- /* Stolen is immediately below Top of Low Usable DRAM */
- pci_read_config_byte(pdev, 0x9c, val);
- base = val 3 27;
- base -= dev_priv-mm.gtt-stolen_size;
+ /* Read D2:F0 Base of Stolen Memory directly */
+ pci_read_config_dword(dev-pdev, 0x5c, base);
+#if 0
} else {
/* Stolen is immediately above Top of Memory */
base = max_low_pfn_mapped PAGE_SHIFT;
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Read the Base of Stolen Memory for 915gm
On Sun, Feb 10, 2013 at 07:38:13PM +, Chris Wilson wrote:
Reading the cspec pays dividends once again, as I found the 'Base of
Stolen Memory' config register so that we can skip the fragile
computation from Top of Usable Draw and use the real value provided by
the BIOS.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Don't really want to dig out the doc, but I so prefer this to the
old way.
Acked-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_stolen.c |9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 130d1db..7f1735c 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -72,13 +72,10 @@ static unsigned long i915_stolen_to_physical(struct
drm_device *dev)
} else if (INTEL_INFO(dev)-gen 3 || IS_G33(dev)) {
/* Read Graphics Base of Stolen Memory directly */
pci_read_config_dword(pdev, 0xA4, base);
-#if 0
} else if (IS_GEN3(dev)) {
- u8 val;
- /* Stolen is immediately below Top of Low Usable DRAM */
- pci_read_config_byte(pdev, 0x9c, val);
- base = val 3 27;
- base -= dev_priv-mm.gtt-stolen_size;
+ /* Read D2:F0 Base of Stolen Memory directly */
+ pci_read_config_dword(dev-pdev, 0x5c, base);
+#if 0
} else {
/* Stolen is immediately above Top of Memory */
base = max_low_pfn_mapped PAGE_SHIFT;
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Read the Base of Stolen Memory for 915gm
Am Sonntag, den 10.02.2013, 19:38 + schrieb Chris Wilson:
Reading the cspec pays dividends once again, as I found the 'Base of
Stolen Memory' config register so that we can skip the fragile
computation from Top of Usable Draw and use the real value provided by
the BIOS.
Nice find. What is the expected functionality change as the code
beforehand was a no-op due to the `if 0`?
If testing is needed, how can this be tested?
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem_stolen.c |9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 130d1db..7f1735c 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -72,13 +72,10 @@ static unsigned long i915_stolen_to_physical(struct
drm_device *dev)
} else if (INTEL_INFO(dev)-gen 3 || IS_G33(dev)) {
/* Read Graphics Base of Stolen Memory directly */
pci_read_config_dword(pdev, 0xA4, base);
-#if 0
} else if (IS_GEN3(dev)) {
- u8 val;
- /* Stolen is immediately below Top of Low Usable DRAM */
- pci_read_config_byte(pdev, 0x9c, val);
- base = val 3 27;
- base -= dev_priv-mm.gtt-stolen_size;
+ /* Read D2:F0 Base of Stolen Memory directly */
+ pci_read_config_dword(dev-pdev, 0x5c, base);
Should macros be defined for the register names?
+#if 0
} else {
/* Stolen is immediately above Top of Memory */
base = max_low_pfn_mapped PAGE_SHIFT;
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Read the Base of Stolen Memory for 915gm
On Sun, Feb 10, 2013 at 11:37:03PM +0100, Paul Menzel wrote: Am Sonntag, den 10.02.2013, 19:38 + schrieb Chris Wilson: Reading the cspec pays dividends once again, as I found the 'Base of Stolen Memory' config register so that we can skip the fragile computation from Top of Usable Draw and use the real value provided by the BIOS. Nice find. What is the expected functionality change as the code beforehand was a no-op due to the `if 0`? It enables the driver to use stolen memory - memory that is hidden from the system and only available, in principal, to the gfx device. If testing is needed, how can this be tested? Boot a 915g/945g. The driver will utilize stolen memory for its ringbuffers and fbcon. - /* Stolen is immediately below Top of Low Usable DRAM */ - pci_read_config_byte(pdev, 0x9c, val); - base = val 3 27; - base -= dev_priv-mm.gtt-stolen_size; + /* Read D2:F0 Base of Stolen Memory directly */ + pci_read_config_dword(dev-pdev, 0x5c, base); Should macros be defined for the register names? My argument is basically where else are you planning to use this value. Each chipset calls it something different and uses a different register, so DRY is not violated and instead of hiding the value in a header, we can define it locally and clearly. Makes adapting it for the next generation much easier as you only have the single location to worry about. (The normal argument for the macro, but in reverse.) -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
