| Message ID | 1420071780-1075-1-git-send-email-kenneth@whitecape.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com)
-------------------------------------Summary-------------------------------------
Platform Delta drm-intel-nightly Series Applied
PNV 363/364 363/364
ILK -1 364/366 363/366
SNB +2-1 443/450 444/450
IVB 496/498 496/498
BYT 288/289 288/289
HSW +2-6 542/564 538/564
BDW 415/417 415/417
-------------------------------------Detailed-------------------------------------
Platform Test drm-intel-nightly Series Applied
*ILK igt_gem_fenced_exec_thrash_no-spare-fences-busy PASS(2, M37) DMESG_WARN(1, M37)
*SNB igt_kms_flip_modeset-vs-vblank-race DMESG_WARN(2, M35) PASS(1, M35)
SNB igt_kms_flip_modeset-vs-vblank-race-interruptible DMESG_WARN(2, M35M22)PASS(1, M35) DMESG_WARN(1, M35)
SNB igt_kms_plane_plane-position-hole-pipe-B-plane-1 DMESG_WARN(1, M35)PASS(2, M35M22) PASS(1, M35)
*HSW igt_kms_flip_flip-vs-expired-vblank PASS(2, M40) DMESG_WARN(1, M40)
*HSW igt_kms_flip_flip-vs-expired-vblank-interruptible PASS(2, M40) DMESG_WARN(1, M40)
*HSW igt_kms_flip_nonexisting-fb PASS(2, M40) DMESG_WARN(1, M40)
*HSW igt_kms_flip_nonexisting-fb-interruptible PASS(2, M40) DMESG_WARN(1, M40)
*HSW igt_kms_flip_single-buffer-flip-vs-dpms-off-vs-modeset PASS(3, M40M19) DMESG_WARN(1, M40)
*HSW igt_kms_plane_plane-panning-bottom-right-pipe-C-plane-1 TIMEOUT(2, M40)PASS(1, M19) PASS(1, M40)
*HSW igt_kms_plane_plane-position-hole-pipe-A-plane-2 PASS(2, M40) DMESG_WARN(1, M40)
HSW igt_pm_rpm_modeset-non-lpsp-stress-no-wait NSPT(1, M19)DMESG_WARN(1, M40)PASS(1, M40) PASS(1, M40)
Note: You need to pay more attention to line start with '*'
On Wed, Dec 31, 2014 at 04:23:00PM -0800, Kenneth Graunke wrote: > Haswell significantly improved the performance of sampler_c messages, > but the optimization appears to be off by default. Later platforms > remove this bit, and apparently always enable the optimization. > > Improves performance in "Counter Strike: Global Offensive" by 18% > at default settings on Iris Pro. > > This may break sampling of paletted formats (P8/A8P8/P8A8). It's > unclear whether it affects sampling of paletted formats in general, > or just the sample_c message (which is never used). > > While libva does have support for using paletted formats (primarily > for OSDs), that support appears to have been broken for at least a > year, so I couldn't observe a regression from this. > > Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> > --- > drivers/gpu/drm/i915/i915_reg.h | 1 + > drivers/gpu/drm/i915/intel_pm.c | 4 ++++ > 2 files changed, 5 insertions(+) > > Resubmitting the patch to unconditionally enable this. I tried to get > libva-intel to use paletted formats, and observe a regression...but the > only thing I found that used it was mplayer's OSD (on screen display). > Even without my patch, the colors were totally wrong with that, and it's > according to a few distro wikis, that's been the case for over a year. > > If libva's code for paletted formats /is/ broken, they could always add > code to disable this bit using the command validator when fixing it. > > Could we try merging this, and back it out if someone reports a > regression? I haven't observed any problems. It's also been quite > stable. Yeah makes sense. When resending please incorporated review feedback (Ville dug out the wa name), I've done that. And I've pasted the additional detail about the libva saga, just for reference (since no one will remember that it's mplayer's OSD which uses this 2 months down the road). Also please cc libva mailing lists next time around as an fyi. Done that too. Queued for -next, thanks for the patch. -Daniel > > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index 40ca873..0f32fd1a 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -6167,6 +6167,7 @@ enum punit_power_well { > #define HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE (1 << 6) > > #define HALF_SLICE_CHICKEN3 0xe184 > +#define HSW_SAMPLE_C_PERFORMANCE (1<<9) > #define GEN8_CENTROID_PIXEL_OPT_DIS (1<<8) > #define GEN8_SAMPLER_POWER_BYPASS_DIS (1<<1) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index 7d99a9c..17e84dc 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -5974,6 +5974,10 @@ static void haswell_init_clock_gating(struct drm_device *dev) > I915_WRITE(GEN7_GT_MODE, > _MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4)); > > + /* Make sample_c messages faster. */ > + I915_WRITE(HALF_SLICE_CHICKEN3, > + _MASKED_BIT_ENABLE(HSW_SAMPLE_C_PERFORMANCE)); > + > /* WaSwitchSolVfFArbitrationPriority:hsw */ > I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) | HSW_ECOCHK_ARB_PRIO_SOL); > > -- > 2.2.1 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Monday, January 05, 2015 02:19:15 PM Daniel Vetter wrote: > On Wed, Dec 31, 2014 at 04:23:00PM -0800, Kenneth Graunke wrote: > > Haswell significantly improved the performance of sampler_c messages, > > but the optimization appears to be off by default. Later platforms > > remove this bit, and apparently always enable the optimization. > > > > Improves performance in "Counter Strike: Global Offensive" by 18% > > at default settings on Iris Pro. > > > > This may break sampling of paletted formats (P8/A8P8/P8A8). It's > > unclear whether it affects sampling of paletted formats in general, > > or just the sample_c message (which is never used). > > > > While libva does have support for using paletted formats (primarily > > for OSDs), that support appears to have been broken for at least a > > year, so I couldn't observe a regression from this. > > > > Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> > > --- > > drivers/gpu/drm/i915/i915_reg.h | 1 + > > drivers/gpu/drm/i915/intel_pm.c | 4 ++++ > > 2 files changed, 5 insertions(+) > > > > Resubmitting the patch to unconditionally enable this. I tried to get > > libva-intel to use paletted formats, and observe a regression...but the > > only thing I found that used it was mplayer's OSD (on screen display). > > Even without my patch, the colors were totally wrong with that, and it's > > according to a few distro wikis, that's been the case for over a year. > > > > If libva's code for paletted formats /is/ broken, they could always add > > code to disable this bit using the command validator when fixing it. > > > > Could we try merging this, and back it out if someone reports a > > regression? I haven't observed any problems. It's also been quite > > stable. > > Yeah makes sense. When resending please incorporated review feedback > (Ville dug out the wa name), I've done that. And I've pasted the > additional detail about the libva saga, just for reference (since no one > will remember that it's mplayer's OSD which uses this 2 months down the > road). > > Also please cc libva mailing lists next time around as an fyi. Done that > too. > > Queued for -next, thanks for the patch. > -Daniel Oh, sorry, I missed that in the review. Thanks, Daniel! --Ken
Hi Kenneth, How did you test OSD ? I can't reproduce the issue you mentioned, OSD works well for me when using mplayer-vaapi with the latest libva/libva-intel-driver master branch. I tried your patch, what surprised me is OSD still works well after applying your patch. It seems your patch didn't disable the palette. Thanks Haihao > On Monday, January 05, 2015 02:19:15 PM Daniel Vetter wrote: > > On Wed, Dec 31, 2014 at 04:23:00PM -0800, Kenneth Graunke wrote: > > > Haswell significantly improved the performance of sampler_c messages, > > > but the optimization appears to be off by default. Later platforms > > > remove this bit, and apparently always enable the optimization. > > > > > > Improves performance in "Counter Strike: Global Offensive" by 18% > > > at default settings on Iris Pro. > > > > > > This may break sampling of paletted formats (P8/A8P8/P8A8). It's > > > unclear whether it affects sampling of paletted formats in general, > > > or just the sample_c message (which is never used). > > > > > > While libva does have support for using paletted formats (primarily > > > for OSDs), that support appears to have been broken for at least a > > > year, so I couldn't observe a regression from this. > > > > > > Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> > > > --- > > > drivers/gpu/drm/i915/i915_reg.h | 1 + > > > drivers/gpu/drm/i915/intel_pm.c | 4 ++++ > > > 2 files changed, 5 insertions(+) > > > > > > Resubmitting the patch to unconditionally enable this. I tried to get > > > libva-intel to use paletted formats, and observe a regression...but the > > > only thing I found that used it was mplayer's OSD (on screen display). > > > Even without my patch, the colors were totally wrong with that, and it's > > > according to a few distro wikis, that's been the case for over a year. > > > > > > If libva's code for paletted formats /is/ broken, they could always add > > > code to disable this bit using the command validator when fixing it. > > > > > > Could we try merging this, and back it out if someone reports a > > > regression? I haven't observed any problems. It's also been quite > > > stable. > > > > Yeah makes sense. When resending please incorporated review feedback > > (Ville dug out the wa name), I've done that. And I've pasted the > > additional detail about the libva saga, just for reference (since no one > > will remember that it's mplayer's OSD which uses this 2 months down the > > road). > > > > Also please cc libva mailing lists next time around as an fyi. Done that > > too. > > > > Queued for -next, thanks for the patch. > > -Daniel > > Oh, sorry, I missed that in the review. > > Thanks, Daniel! > > --Ken > _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tuesday, January 06, 2015 01:11:53 PM Xiang, Haihao wrote: > > Hi Kenneth, > > How did you test OSD ? I can't reproduce the issue you mentioned, OSD > works well for me when using mplayer-vaapi with the latest > libva/libva-intel-driver master branch. > > I tried your patch, what surprised me is OSD still works well after > applying your patch. It seems your patch didn't disable the palette. > > Thanks > Haihao I ran: mplayer -osdlevel 3 -vo vaapi big_buck_bunny_720p_stereo.ogg For me, the OSD text is solid green, with hard edges. If you use "-vo gl" or "-vo xv", the OSD is solid white text with a black border around it. I presume that it's supposed to be white with vaapi as well, but I guess I'm not entirely sure. It's possible that the optimization doesn't affect the palette as long as you never use sample_c with the paletted textures. --Ken
On Mon, 2015-01-05 at 21:54 -0800, Kenneth Graunke wrote: > On Tuesday, January 06, 2015 01:11:53 PM Xiang, Haihao wrote: > > > > Hi Kenneth, > > > > How did you test OSD ? I can't reproduce the issue you mentioned, OSD > > works well for me when using mplayer-vaapi with the latest > > libva/libva-intel-driver master branch. > > > > I tried your patch, what surprised me is OSD still works well after > > applying your patch. It seems your patch didn't disable the palette. > > > > Thanks > > Haihao > > I ran: > > mplayer -osdlevel 3 -vo vaapi big_buck_bunny_720p_stereo.ogg > > For me, the OSD text is solid green, with hard edges. The OSD text is white for me when using mplayer -osdlevel 3 -vo vaapi xxx. If possible, could you update your mplayer ? > > If you use "-vo gl" or "-vo xv", the OSD is solid white text with a black > border around it. I presume that it's supposed to be white with vaapi as > well, but I guess I'm not entirely sure. > > It's possible that the optimization doesn't affect the palette as long as > you never use sample_c with the paletted textures. I verified the palette takes effect in the following way: 1. Only support P8A8 format in the driver 2. ran the above command and I saw white OSD text 3. Only support P4A4 format in the driver and don't use 3DSTATE_SAMPLER_PALETTE_LOAD0 to load the value to the texture palette, so the palette keeps unchanged. 4. ran the above command and I saw black OSD text. 5. Load the right value to the texture palette and ran the above command again, I saw white OSD text. Hence I think sample_c with the paletted textures is used in the driver. > > --Ken
On Tue, 2015-01-06 at 14:39 +0800, Xiang, Haihao wrote: > On Mon, 2015-01-05 at 21:54 -0800, Kenneth Graunke wrote: > > On Tuesday, January 06, 2015 01:11:53 PM Xiang, Haihao wrote: > > > > > > Hi Kenneth, > > > > > > How did you test OSD ? I can't reproduce the issue you mentioned, OSD > > > works well for me when using mplayer-vaapi with the latest > > > libva/libva-intel-driver master branch. > > > > > > I tried your patch, what surprised me is OSD still works well after > > > applying your patch. It seems your patch didn't disable the palette. > > > > > > Thanks > > > Haihao > > > > I ran: > > > > mplayer -osdlevel 3 -vo vaapi big_buck_bunny_720p_stereo.ogg > > > > For me, the OSD text is solid green, with hard edges. > > The OSD text is white for me when using mplayer -osdlevel 3 -vo vaapi > xxx. If possible, could you update your mplayer ? > > > > > If you use "-vo gl" or "-vo xv", the OSD is solid white text with a black > > border around it. I presume that it's supposed to be white with vaapi as > > well, but I guess I'm not entirely sure. > > > > It's possible that the optimization doesn't affect the palette as long as > > you never use sample_c with the paletted textures. > > > I verified the palette takes effect in the following way: > > 1. Only support P8A8 format in the driver > > 2. ran the above command and I saw white OSD text > > 3. Only support P4A4 format in the driver and don't use > 3DSTATE_SAMPLER_PALETTE_LOAD0 to load the value to the texture palette, > so the palette keeps unchanged. > > 4. ran the above command and I saw black OSD text. > > 5. Load the right value to the texture palette and ran the above command > again, I saw white OSD text. > > Hence I think sample_c with the paletted textures is used in the driver. Sorry, libva driver doesn't use sample_c message, I mean the paletted texture is used. However corroding to the doc, Palette is disabled for fast mode. > > > > > --Ken > > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tuesday, January 06, 2015 02:39:36 PM Xiang, Haihao wrote: > On Mon, 2015-01-05 at 21:54 -0800, Kenneth Graunke wrote: > > On Tuesday, January 06, 2015 01:11:53 PM Xiang, Haihao wrote: > > > > > > Hi Kenneth, > > > > > > How did you test OSD ? I can't reproduce the issue you mentioned, OSD > > > works well for me when using mplayer-vaapi with the latest > > > libva/libva-intel-driver master branch. > > > > > > I tried your patch, what surprised me is OSD still works well after > > > applying your patch. It seems your patch didn't disable the palette. > > > > > > Thanks > > > Haihao > > > > I ran: > > > > mplayer -osdlevel 3 -vo vaapi big_buck_bunny_720p_stereo.ogg > > > > For me, the OSD text is solid green, with hard edges. > > The OSD text is white for me when using mplayer -osdlevel 3 -vo vaapi > xxx. If possible, could you update your mplayer ? Huh. I'm using the Arch Linux package of mplayer-vaapi 36265-13, which seems to be the most recent subversion commit ID. I've never seen white text on my Haswell system - it seems to be consistently dark green. > > If you use "-vo gl" or "-vo xv", the OSD is solid white text with a black > > border around it. I presume that it's supposed to be white with vaapi as > > well, but I guess I'm not entirely sure. > > > > It's possible that the optimization doesn't affect the palette as long as > > you never use sample_c with the paletted textures. > > I verified the palette takes effect in the following way: > > 1. Only support P8A8 format in the driver > > 2. ran the above command and I saw white OSD text > > 3. Only support P4A4 format in the driver and don't use > 3DSTATE_SAMPLER_PALETTE_LOAD0 to load the value to the texture palette, > so the palette keeps unchanged. > > 4. ran the above command and I saw black OSD text. > > 5. Load the right value to the texture palette and ran the above command > again, I saw white OSD text. > > Hence I think sample_c with the paletted textures is used in the driver. That sounds like the palette is actually working, then. Great :) I doubt that libva would use sample_c - sampling with a shadow comparison? It looks like it just uses sample and sample+killpix. I'm pretty sure the sample_c optimization just uses the palette memory as storage for some stuff, so it's quite possible it just works if you're only using sample and sample+killpix. --Ken
On Mon, 2015-01-05 at 23:03 -0800, Kenneth Graunke wrote: > On Tuesday, January 06, 2015 02:39:36 PM Xiang, Haihao wrote: > > On Mon, 2015-01-05 at 21:54 -0800, Kenneth Graunke wrote: > > > On Tuesday, January 06, 2015 01:11:53 PM Xiang, Haihao wrote: > > > > > > > > Hi Kenneth, > > > > > > > > How did you test OSD ? I can't reproduce the issue you mentioned, OSD > > > > works well for me when using mplayer-vaapi with the latest > > > > libva/libva-intel-driver master branch. > > > > > > > > I tried your patch, what surprised me is OSD still works well after > > > > applying your patch. It seems your patch didn't disable the palette. > > > > > > > > Thanks > > > > Haihao > > > > > > I ran: > > > > > > mplayer -osdlevel 3 -vo vaapi big_buck_bunny_720p_stereo.ogg > > > > > > For me, the OSD text is solid green, with hard edges. > > > > The OSD text is white for me when using mplayer -osdlevel 3 -vo vaapi > > xxx. If possible, could you update your mplayer ? > > Huh. I'm using the Arch Linux package of mplayer-vaapi 36265-13, > which seems to be the most recent subversion commit ID. I've never seen > white text on my Haswell system - it seems to be consistently dark green. > > > If you use "-vo gl" or "-vo xv", the OSD is solid white text with a black > > > border around it. I presume that it's supposed to be white with vaapi as > > > well, but I guess I'm not entirely sure. > > > > > > It's possible that the optimization doesn't affect the palette as long as > > > you never use sample_c with the paletted textures. > > > > I verified the palette takes effect in the following way: > > > > 1. Only support P8A8 format in the driver > > > > 2. ran the above command and I saw white OSD text > > > > 3. Only support P4A4 format in the driver and don't use > > 3DSTATE_SAMPLER_PALETTE_LOAD0 to load the value to the texture palette, > > so the palette keeps unchanged. > > > > 4. ran the above command and I saw black OSD text. > > > > 5. Load the right value to the texture palette and ran the above command > > again, I saw white OSD text. > > > > Hence I think sample_c with the paletted textures is used in the driver. > > That sounds like the palette is actually working, then. Great :) > > I doubt that libva would use sample_c - sampling with a shadow comparison? > It looks like it just uses sample and sample+killpix. You are right, libva driver doesn't use sample_c message. > I'm pretty sure the sample_c optimization just uses the palette memory as > storage for some stuff, so it's quite possible it just works if you're > only using sample and sample+killpix. Thanks for the explanation, it makes sense to me. > > --Ken
On Tue, Jan 06, 2015 at 03:15:39PM +0800, Xiang, Haihao wrote: > On Mon, 2015-01-05 at 23:03 -0800, Kenneth Graunke wrote: > > On Tuesday, January 06, 2015 02:39:36 PM Xiang, Haihao wrote: > > > On Mon, 2015-01-05 at 21:54 -0800, Kenneth Graunke wrote: > > > > On Tuesday, January 06, 2015 01:11:53 PM Xiang, Haihao wrote: > > > > > > > > > > Hi Kenneth, > > > > > > > > > > How did you test OSD ? I can't reproduce the issue you mentioned, OSD > > > > > works well for me when using mplayer-vaapi with the latest > > > > > libva/libva-intel-driver master branch. > > > > > > > > > > I tried your patch, what surprised me is OSD still works well after > > > > > applying your patch. It seems your patch didn't disable the palette. > > > > > > > > > > Thanks > > > > > Haihao > > > > > > > > I ran: > > > > > > > > mplayer -osdlevel 3 -vo vaapi big_buck_bunny_720p_stereo.ogg > > > > > > > > For me, the OSD text is solid green, with hard edges. > > > > > > The OSD text is white for me when using mplayer -osdlevel 3 -vo vaapi > > > xxx. If possible, could you update your mplayer ? > > > > Huh. I'm using the Arch Linux package of mplayer-vaapi 36265-13, > > which seems to be the most recent subversion commit ID. I've never seen > > white text on my Haswell system - it seems to be consistently dark green. > > > > > If you use "-vo gl" or "-vo xv", the OSD is solid white text with a black > > > > border around it. I presume that it's supposed to be white with vaapi as > > > > well, but I guess I'm not entirely sure. > > > > > > > > It's possible that the optimization doesn't affect the palette as long as > > > > you never use sample_c with the paletted textures. > > > > > > I verified the palette takes effect in the following way: > > > > > > 1. Only support P8A8 format in the driver > > > > > > 2. ran the above command and I saw white OSD text > > > > > > 3. Only support P4A4 format in the driver and don't use > > > 3DSTATE_SAMPLER_PALETTE_LOAD0 to load the value to the texture palette, > > > so the palette keeps unchanged. > > > > > > 4. ran the above command and I saw black OSD text. > > > > > > 5. Load the right value to the texture palette and ran the above command > > > again, I saw white OSD text. > > > > > > Hence I think sample_c with the paletted textures is used in the driver. > > > > That sounds like the palette is actually working, then. Great :) > > > > I doubt that libva would use sample_c - sampling with a shadow comparison? > > It looks like it just uses sample and sample+killpix. > > You are right, libva driver doesn't use sample_c message. > > > I'm pretty sure the sample_c optimization just uses the palette memory as > > storage for some stuff, so it's quite possible it just works if you're > > only using sample and sample+killpix. > > Thanks for the explanation, it makes sense to me. Thanks for digging into this some more, I've added the above discussion in a quote to the commit message. Thanks, Daniel
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 40ca873..0f32fd1a 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -6167,6 +6167,7 @@ enum punit_power_well { #define HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE (1 << 6) #define HALF_SLICE_CHICKEN3 0xe184 +#define HSW_SAMPLE_C_PERFORMANCE (1<<9) #define GEN8_CENTROID_PIXEL_OPT_DIS (1<<8) #define GEN8_SAMPLER_POWER_BYPASS_DIS (1<<1) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 7d99a9c..17e84dc 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -5974,6 +5974,10 @@ static void haswell_init_clock_gating(struct drm_device *dev) I915_WRITE(GEN7_GT_MODE, _MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4)); + /* Make sample_c messages faster. */ + I915_WRITE(HALF_SLICE_CHICKEN3, + _MASKED_BIT_ENABLE(HSW_SAMPLE_C_PERFORMANCE)); + /* WaSwitchSolVfFArbitrationPriority:hsw */ I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) | HSW_ECOCHK_ARB_PRIO_SOL);
Haswell significantly improved the performance of sampler_c messages, but the optimization appears to be off by default. Later platforms remove this bit, and apparently always enable the optimization. Improves performance in "Counter Strike: Global Offensive" by 18% at default settings on Iris Pro. This may break sampling of paletted formats (P8/A8P8/P8A8). It's unclear whether it affects sampling of paletted formats in general, or just the sample_c message (which is never used). While libva does have support for using paletted formats (primarily for OSDs), that support appears to have been broken for at least a year, so I couldn't observe a regression from this. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> --- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 4 ++++ 2 files changed, 5 insertions(+) Resubmitting the patch to unconditionally enable this. I tried to get libva-intel to use paletted formats, and observe a regression...but the only thing I found that used it was mplayer's OSD (on screen display). Even without my patch, the colors were totally wrong with that, and it's according to a few distro wikis, that's been the case for over a year. If libva's code for paletted formats /is/ broken, they could always add code to disable this bit using the command validator when fixing it. Could we try merging this, and back it out if someone reports a regression? I haven't observed any problems. It's also been quite stable.