Re: [Intel-gfx] [PATCH v2 03/11] drm/i915: Use str_yes_no()
On Wed, Jan 26, 2022 at 01:39:43AM -0800, Lucas De Marchi wrote: > Remove the local yesno() implementation and adopt the str_yes_no() from > linux/string_helpers.h. > > Signed-off-by: Lucas De Marchi > Acked-by: Daniel Vetter > Acked-by: Jani Nikula Reviewed-by: Matt Roper > --- > drivers/gpu/drm/i915/display/intel_display.c | 23 +++ > .../drm/i915/display/intel_display_debugfs.c | 66 +++ > .../drm/i915/display/intel_display_trace.h| 6 +- > drivers/gpu/drm/i915/display/intel_dp.c | 12 ++-- > drivers/gpu/drm/i915/display/intel_fbc.c | 4 +- > drivers/gpu/drm/i915/display/intel_hdmi.c | 3 +- > drivers/gpu/drm/i915/display/intel_sprite.c | 6 +- > .../gpu/drm/i915/gem/selftests/huge_pages.c | 9 +-- > .../drm/i915/gem/selftests/i915_gem_context.c | 7 +- > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 9 +-- > .../drm/i915/gt/intel_execlists_submission.c | 7 +- > drivers/gpu/drm/i915/gt/intel_gt_pm.c | 3 +- > drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 52 --- > drivers/gpu/drm/i915/gt/intel_reset.c | 3 +- > drivers/gpu/drm/i915/gt/intel_rps.c | 13 ++-- > drivers/gpu/drm/i915/gt/intel_sseu.c | 9 ++- > drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 10 +-- > drivers/gpu/drm/i915/gt/selftest_timeline.c | 3 +- > drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 3 +- > drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 4 +- > drivers/gpu/drm/i915/gt/uc/intel_uc.c | 10 +-- > drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c | 20 +++--- > drivers/gpu/drm/i915/i915_debugfs.c | 15 +++-- > drivers/gpu/drm/i915/i915_gpu_error.c | 9 +-- > drivers/gpu/drm/i915/i915_params.c| 5 +- > drivers/gpu/drm/i915/i915_utils.h | 5 -- > drivers/gpu/drm/i915/intel_device_info.c | 8 ++- > drivers/gpu/drm/i915/intel_dram.c | 10 +-- > drivers/gpu/drm/i915/intel_pm.c | 10 +-- > drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 4 +- > drivers/gpu/drm/i915/selftests/i915_active.c | 3 +- > 31 files changed, 203 insertions(+), 148 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index 80bc52425e47..bd453861088e 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -32,6 +32,7 @@ > #include > #include > #include > +#include > #include > > #include > @@ -3008,7 +3009,7 @@ static int intel_crtc_compute_config(struct intel_crtc > *crtc, > drm_dbg_kms(&dev_priv->drm, > "requested pixel clock (%d kHz) too high (max: %d > kHz, double wide: %s)\n", > pipe_mode->crtc_clock, clock_limit, > - yesno(pipe_config->double_wide)); > + str_yes_no(pipe_config->double_wide)); > return -EINVAL; > } > > @@ -5586,7 +5587,7 @@ static void intel_dump_plane_state(const struct > intel_plane_state *plane_state) > drm_dbg_kms(&i915->drm, > "[PLANE:%d:%s] fb: [NOFB], visible: %s\n", > plane->base.base.id, plane->base.name, > - yesno(plane_state->uapi.visible)); > + str_yes_no(plane_state->uapi.visible)); > return; > } > > @@ -5594,7 +5595,7 @@ static void intel_dump_plane_state(const struct > intel_plane_state *plane_state) > "[PLANE:%d:%s] fb: [FB:%d] %ux%u format = %p4cc modifier = > 0x%llx, visible: %s\n", > plane->base.base.id, plane->base.name, > fb->base.id, fb->width, fb->height, &fb->format->format, > - fb->modifier, yesno(plane_state->uapi.visible)); > + fb->modifier, str_yes_no(plane_state->uapi.visible)); > drm_dbg_kms(&i915->drm, "\trotation: 0x%x, scaler: %d\n", > plane_state->hw.rotation, plane_state->scaler_id); > if (plane_state->uapi.visible) > @@ -5617,7 +5618,7 @@ static void intel_dump_pipe_config(const struct > intel_crtc_state *pipe_config, > > drm_dbg_kms(&dev_priv->drm, "[CRTC:%d:%s] enable: %s %s\n", > crtc->base.base.id, crtc->base.name, > - yesno(pipe_config->hw.enable), context); > + str_yes_no(pipe_config->hw.enable), context); > > if (!pipe_config->hw.enable) > g
Re: [Intel-gfx] [PATCH v2 04/11] drm/i915: Use str_enable_disable()
On Wed, Jan 26, 2022 at 01:39:44AM -0800, Lucas De Marchi wrote:
> Remove the local enabledisable() implementation and adopt the
> str_enable_disable() from linux/string_helpers.h.
>
> Signed-off-by: Lucas De Marchi
> Acked-by: Daniel Vetter
> Acked-by: Jani Nikula
There's an open-coded version of this in display/intel_pps.c,
intel_pps_backlight_power(). Up to you whether you squash it into this
patch or convert it as a follow-up. Either way.
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 4 +++-
> drivers/gpu/drm/i915/display/intel_display_power.c | 4 +++-
> drivers/gpu/drm/i915/display/intel_dp.c| 8
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 3 ++-
> drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 4 +++-
> drivers/gpu/drm/i915/i915_utils.h | 5 -
> 6 files changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 2f20abc5122d..4b35a8597632 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -25,6 +25,8 @@
> *
> */
>
> +#include
> +
> #include
> #include
>
> @@ -2152,7 +2154,7 @@ static void
> intel_dp_sink_set_msa_timing_par_ignore_state(struct intel_dp *intel
> enable ? DP_MSA_TIMING_PAR_IGNORE_EN : 0) <= 0)
> drm_dbg_kms(&i915->drm,
> "Failed to %s MSA_TIMING_PAR_IGNORE in the sink\n",
> - enabledisable(enable));
> + str_enable_disable(enable));
> }
>
> static void intel_dp_sink_set_fec_ready(struct intel_dp *intel_dp,
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 369317805d24..1f77cb9edddf 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -3,6 +3,8 @@
> * Copyright © 2019 Intel Corporation
> */
>
> +#include
> +
> #include "i915_drv.h"
> #include "i915_irq.h"
> #include "intel_cdclk.h"
> @@ -5302,7 +5304,7 @@ static void gen9_dbuf_slice_set(struct drm_i915_private
> *dev_priv,
> state = intel_de_read(dev_priv, reg) & DBUF_POWER_STATE;
> drm_WARN(&dev_priv->drm, enable != state,
>"DBuf slice %d power %s timeout!\n",
> - slice, enabledisable(enable));
> + slice, str_enable_disable(enable));
> }
>
> void gen9_dbuf_slices_update(struct drm_i915_private *dev_priv,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 62c1535d696d..933fc316ea53 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1987,7 +1987,7 @@ void intel_dp_sink_set_decompression_state(struct
> intel_dp *intel_dp,
> if (ret < 0)
> drm_dbg_kms(&i915->drm,
> "Failed to %s sink decompression state\n",
> - enabledisable(enable));
> + str_enable_disable(enable));
> }
>
> static void
> @@ -2463,7 +2463,7 @@ void intel_dp_configure_protocol_converter(struct
> intel_dp *intel_dp,
> if (drm_dp_dpcd_writeb(&intel_dp->aux,
> DP_PROTOCOL_CONVERTER_CONTROL_0, tmp) != 1)
> drm_dbg_kms(&i915->drm, "Failed to %s protocol converter HDMI
> mode\n",
> - enabledisable(intel_dp->has_hdmi_sink));
> + str_enable_disable(intel_dp->has_hdmi_sink));
>
> tmp = crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444 &&
> intel_dp->dfp.ycbcr_444_to_420 ?
> DP_CONVERSION_TO_YCBCR420_ENABLE : 0;
> @@ -2472,7 +2472,7 @@ void intel_dp_configure_protocol_converter(struct
> intel_dp *intel_dp,
> DP_PROTOCOL_CONVERTER_CONTROL_1, tmp) != 1)
> drm_dbg_kms(&i915->drm,
> "Failed to %s protocol converter YCbCr 4:2:0
> conversion mode\n",
> - enabledisable(intel_dp->dfp.ycbcr_444_to_420));
> + str_enable_disable(intel_dp->dfp.ycbcr_444_to_420));
>
> tmp = 0;
> if (intel_dp->dfp.rgb_to_ycbcr) {
> @@ -2510,7 +2510,7 @@ void intel_dp_configure_protocol_converter(struct
> intel_dp *intel_dp,
> if (drm_dp_pcon_convert_rgb_
Re: [Intel-gfx] [PATCH v2 05/11] drm/i915: Use str_enabled_disabled()
On Wed, Jan 26, 2022 at 01:39:45AM -0800, Lucas De Marchi wrote:
> Remove the local enableddisabled() implementation and adopt the
> str_enabled_disabled() from linux/string_helpers.h.
>
> Signed-off-by: Lucas De Marchi
> Acked-by: Daniel Vetter
> Acked-by: Jani Nikula
There's two open-coded versions of this in intel_dp_hdcp.c
(intel_dp_mst_hdcp_stream_encryption() and
intel_dp_mst_hdcp2_stream_encryption()) that you might want to convert
as well. Up to you whether you squash them into this patch or convert
them as a separate patch. Either way,
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_backlight.c | 3 ++-
> drivers/gpu/drm/i915/display/intel_display.c | 16
> .../gpu/drm/i915/display/intel_display_debugfs.c | 8
> drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 7 ---
> drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 3 ++-
> drivers/gpu/drm/i915/gt/intel_engine_cs.c| 2 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c| 2 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 2 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c| 2 +-
> drivers/gpu/drm/i915/gt/uc/intel_uc.c| 4 ++--
> drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
> drivers/gpu/drm/i915/i915_driver.c | 4 +++-
> drivers/gpu/drm/i915/i915_utils.h| 6 +-
> drivers/gpu/drm/i915/intel_pm.c | 4 ++--
> 14 files changed, 33 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c
> b/drivers/gpu/drm/i915/display/intel_backlight.c
> index 98f7ea44042f..c8e1fc53a881 100644
> --- a/drivers/gpu/drm/i915/display/intel_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_backlight.c
> @@ -5,6 +5,7 @@
>
> #include
> #include
> +#include
>
> #include "intel_backlight.h"
> #include "intel_connector.h"
> @@ -1633,7 +1634,7 @@ int intel_backlight_setup(struct intel_connector
> *connector, enum pipe pipe)
> drm_dbg_kms(&dev_priv->drm,
> "Connector %s backlight initialized, %s, brightness
> %u/%u\n",
> connector->base.name,
> - enableddisabled(panel->backlight.enabled),
> + str_enabled_disabled(panel->backlight.enabled),
> panel->backlight.level, panel->backlight.max);
>
> return 0;
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index bd453861088e..8920bdb53b7b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -3110,8 +3110,8 @@ static void intel_panel_sanitize_ssc(struct
> drm_i915_private *dev_priv)
> if (dev_priv->vbt.lvds_use_ssc != bios_lvds_use_ssc) {
> drm_dbg_kms(&dev_priv->drm,
> "SSC %s by BIOS, overriding VBT which says
> %s\n",
> - enableddisabled(bios_lvds_use_ssc),
> -
> enableddisabled(dev_priv->vbt.lvds_use_ssc));
> + str_enabled_disabled(bios_lvds_use_ssc),
> +
> str_enabled_disabled(dev_priv->vbt.lvds_use_ssc));
> dev_priv->vbt.lvds_use_ssc = bios_lvds_use_ssc;
> }
> }
> @@ -5648,7 +5648,7 @@ static void intel_dump_pipe_config(const struct
> intel_crtc_state *pipe_config,
> pipe_config->bigjoiner ? "master" : "no");
>
> drm_dbg_kms(&dev_priv->drm, "splitter: %s, link count %d, overlap %d\n",
> - enableddisabled(pipe_config->splitter.enable),
> + str_enabled_disabled(pipe_config->splitter.enable),
> pipe_config->splitter.link_count,
> pipe_config->splitter.pixel_overlap);
>
> @@ -5736,7 +5736,7 @@ static void intel_dump_pipe_config(const struct
> intel_crtc_state *pipe_config,
> drm_dbg_kms(&dev_priv->drm,
> "pch pfit: " DRM_RECT_FMT ", %s, force thru: %s\n",
> DRM_RECT_ARG(&pipe_config->pch_pfit.dst),
> - enableddisabled(pipe_config->pch_pfit.enabled),
> + str_enabled_disabled(pipe_config->pch_pfit.enabled),
> str_yes_no(pipe_config->pch_pfit.force_thru));
>
> drm_dbg_kms(&dev_priv->drm, "ips: %i, double wide: %i\n",
> @@ -10300,7 +10300,7
Re: [Intel-gfx] [PATCH v2 06/11] drm/i915: Use str_on_off()
On Wed, Jan 26, 2022 at 01:39:46AM -0800, Lucas De Marchi wrote: > Remove the local onoff() implementation and adopt the > str_on_off() from linux/string_helpers.h. > > Signed-off-by: Lucas De Marchi > Acked-by: Daniel Vetter > Acked-by: Jani Nikula Reviewed-by: Matt Roper > --- > drivers/gpu/drm/i915/display/g4x_dp.c | 6 -- > drivers/gpu/drm/i915/display/intel_display.c | 7 --- > drivers/gpu/drm/i915/display/intel_display_trace.h | 3 ++- > drivers/gpu/drm/i915/display/intel_dpll.c | 3 ++- > drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 7 +-- > drivers/gpu/drm/i915/display/intel_fdi.c | 8 +--- > drivers/gpu/drm/i915/display/vlv_dsi_pll.c | 3 ++- > drivers/gpu/drm/i915/gt/intel_rc6.c| 5 +++-- > drivers/gpu/drm/i915/i915_utils.h | 5 - > drivers/gpu/drm/i915/vlv_suspend.c | 3 ++- > 10 files changed, 29 insertions(+), 21 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c > b/drivers/gpu/drm/i915/display/g4x_dp.c > index f37677df6ebf..3e729bff1232 100644 > --- a/drivers/gpu/drm/i915/display/g4x_dp.c > +++ b/drivers/gpu/drm/i915/display/g4x_dp.c > @@ -5,6 +5,8 @@ > * DisplayPort support for G4x,ILK,SNB,IVB,VLV,CHV (HSW+ handled by the DDI > code). > */ > > +#include > + > #include "g4x_dp.h" > #include "intel_audio.h" > #include "intel_backlight.h" > @@ -191,7 +193,7 @@ static void assert_dp_port(struct intel_dp *intel_dp, > bool state) > I915_STATE_WARN(cur_state != state, > "[ENCODER:%d:%s] state assertion failure (expected %s, > current %s)\n", > dig_port->base.base.base.id, dig_port->base.base.name, > - onoff(state), onoff(cur_state)); > + str_on_off(state), str_on_off(cur_state)); > } > #define assert_dp_port_disabled(d) assert_dp_port((d), false) > > @@ -201,7 +203,7 @@ static void assert_edp_pll(struct drm_i915_private > *dev_priv, bool state) > > I915_STATE_WARN(cur_state != state, > "eDP PLL state assertion failure (expected %s, current > %s)\n", > - onoff(state), onoff(cur_state)); > + str_on_off(state), str_on_off(cur_state)); > } > #define assert_edp_pll_enabled(d) assert_edp_pll((d), true) > #define assert_edp_pll_disabled(d) assert_edp_pll((d), false) > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index 8920bdb53b7b..49f994f36fce 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -377,7 +377,7 @@ static void wait_for_pipe_scanline_moving(struct > intel_crtc *crtc, bool state) > if (wait_for(pipe_scanline_is_moving(dev_priv, pipe) == state, 100)) > drm_err(&dev_priv->drm, > "pipe %c scanline %s wait timed out\n", > - pipe_name(pipe), onoff(state)); > + pipe_name(pipe), str_on_off(state)); > } > > static void intel_wait_for_pipe_scanline_stopped(struct intel_crtc *crtc) > @@ -435,7 +435,7 @@ void assert_transcoder(struct drm_i915_private *dev_priv, > I915_STATE_WARN(cur_state != state, > "transcoder %s assertion failure (expected %s, current > %s)\n", > transcoder_name(cpu_transcoder), > - onoff(state), onoff(cur_state)); > + str_on_off(state), str_on_off(cur_state)); > } > > static void assert_plane(struct intel_plane *plane, bool state) > @@ -447,7 +447,8 @@ static void assert_plane(struct intel_plane *plane, bool > state) > > I915_STATE_WARN(cur_state != state, > "%s assertion failure (expected %s, current %s)\n", > - plane->base.name, onoff(state), onoff(cur_state)); > + plane->base.name, str_on_off(state), > + str_on_off(cur_state)); > } > > #define assert_plane_enabled(p) assert_plane(p, true) > diff --git a/drivers/gpu/drm/i915/display/intel_display_trace.h > b/drivers/gpu/drm/i915/display/intel_display_trace.h > index dcdd242fffd9..2dd5a4b7f5d8 100644 > --- a/drivers/gpu/drm/i915/display/intel_display_trace.h > +++ b/drivers/gpu/drm/i915/display/intel_display_trace.h > @@ -9,6 +9,7 @@ > #if !defined(__INTEL_DISPLAY_TRACE_H__) || defined(TRACE_HEADER_MULTI_READ) > #define __INTEL_DISPLAY_TRACE_H__ > > +#include > #include > #include > &g
Re: [PATCH] drm/gamma: Clarify gamma lut uapi
On Fri, Mar 29, 2019 at 10:20:27AM +0100, Daniel Vetter wrote:
> Interpreting it as a 0.16 fixed point means we can't accurately
> represent 1.0. Which is one of the values we really should be able to
> represent.
>
> Since most (all?) luts have lower precision this will only affect
> rounding of 0x.
>
> Cc: Uma Shankar
> Cc: Ville Syrjälä
> Cc: Shashank Sharma
> Cc: "Kumar, Kiran S"
> Cc: Kausal Malladi
> Cc: Lionel Landwerlin
> Cc: Matt Roper
> Cc: Rob Bradford
> Cc: Daniel Stone
> Cc: Stefan Schake
> Cc: Eric Anholt
> Cc: Maarten Lankhorst
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: amd-gfx@lists.freedesktop.org
> Cc: James (Qian) Wang
> Cc: Liviu Dudau
> Cc: Mali DP Maintainers
> Cc: CK Hu
> Cc: Philipp Zabel
> Cc: Yannick Fertre
> Cc: Philippe Cornu
> Cc: Benjamin Gaignard
> Cc: Vincent Abriou
> Cc: Tomi Valkeinen
> Cc: Boris Brezillon
> Signed-off-by: Daniel Vetter Signed-off-by: Daniel
> Vetter
Looks like you're missing a newline between your two s-o-b's. But the
patch is
Reviewed-by: Matt Roper
> ---
> include/uapi/drm/drm_mode.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 09d72966899a..83cd1636b9be 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -621,7 +621,8 @@ struct drm_color_ctm {
>
> struct drm_color_lut {
> /*
> - * Data is U0.16 fixed point format.
> + * Values are mapped linearly to 0.0 - 1.0 range, with 0x0 == 0.0 and
> + * 0x == 1.0.
>*/
> __u16 red;
> __u16 green;
> --
> 2.20.1
>
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [Intel-gfx] [PATCH RFC 2/5] cgroup: Add mechanism to register vendor specific DRM devices
On Mon, Dec 03, 2018 at 06:46:01AM +, Ho, Kenny wrote: > Hey Matt, > > On Fri, Nov 30, 2018 at 5:22 PM Matt Roper wrote: > > I think Joonas is describing something closer in > > design to the cgroup-v2 "cpu" controller, which partitions the general > > time/usage allocated to via cgroup; afaiu, "cpu" doesn't really care > > which specific core the tasks run on, just the relative weights that > > determine how much time they get to run on any of the cores. > > Depending on the level of optimization one wants to do, I think people > care about which cpu core a task runs on. Modern processors are no > longer a monolithic 'thing'. At least for AMD, there are multiple > cpus on a core complex (CCX), multiple CCX on a die, and multiple dies > on a processor. A task running on cpu 0 and cpu 1 on die 0 will > behave very differently from a task running on core 0s on die 0 and > die 1 on the same socket. > (https://en.wikichip.org/wiki/amd/microarchitectures/zen#Die-die_memory_latencies) > > It's not just an AMD thing either. Here is an open issue on Intel's > architecture: > https://github.com/kubernetes/kubernetes/issues/67355 > > and a proposed solution using cpu affinity > https://github.com/kubernetes/community/blob/630acc487c80e4981a232cdd8400eb8207119788/keps/sig-node/0030-qos-class-cpu-affinity.md#proposal > (by one of your colleagues.) Right, I didn't mean to imply that the use case wasn't valid, I was just referring to how I believe the cgroup-v2 'cpu' controller (i.e., cpu_cgrp_subsys) currently behaves, as a contrast to the behavior of the cgroup-v1 'cpuset' controller. I can definitely understand your motivation for wanting something along the lines of a "gpuset" controller, but as far as I know, that just isn't something that's possible to implement on a lot of GPU's. > > The time-based sharing below is also something we are thinking about, > but it's personally not as exciting as the resource-based sharing for > me because the time-share use case has already been addressed by our > SRIOV/virtualization products. We can potentially have different > level of time sharing using cgroup though (in addition to SRIOV), > potentially trading efficiency against isolation. That said, I think > the time-based approach maybe orthogonal to the resource-based > approach (orthogonal in the sense that both are needed depending on > the usage.) Makes sense. Matt > > Regards, > Kenny > > > > It sounds like with your hardware, your kernel driver is able to specify > > exactly which subset of GPU EU's a specific GPU context winds up running > > on. However I think there are a lot of platforms that don't allow that > > kind of low-level control. E.g., I don't think we can do that on Intel > > hardware; we have a handful of high-level GPU engines that we can submit > > different types of batchbuffers to (render, blitter, media, etc.). What > > we can do is use GPU preemption to limit how much time specific GPU > > contexts get to run on the render engine before the engine is reclaimed > > for use by a different context. > > > > Using a %gputime approach like Joonas is suggesting could be handled in > > a driver by reserving specific subsets of EU's on hardware like yours > > that's capable of doing that, whereas it could be mostly handled on > > other types of hardware via GPU engine preemption. > > > > I think either approach "gpu_euset" or "%gputime" should map well to a > > cgroup controller implementation. Granted, neither one solves the > > specific use case I was working on earlier this year where we need > > unfair (starvation-okay) scheduling that will run contexts strictly > > according to priority (i.e., lower priority contexts will never run at > > all unless all higher priority contexts have completed all of their > > submitted work), but that's a pretty specialized use case that we'll > > probably need to handle in a different manner anyway. > > > > > > Matt > > > > > > > Regards, > > > Kennny > > > > > > > > > > > > That combined with the "GPU memory usable" property should be a good > > > > > > starting point to start subdividing the GPU resources for multiple > > > > > > users. > > > > > > > > > > > > Regards, Joonas > > > > > > > > > > > > > > > > > > > > Your feedback is highly appreciated. > > > > > > >
Re: [Intel-gfx] [PATCH RFC 2/5] cgroup: Add mechanism to register vendor specific DRM devices
> > > > > > will never be acceptable to be managed under cgroup? Let say a user > > > > > > > > > > I wouldn't say never but whatever which gets included as a cgroup > > > > > controller should have clearly defined resource abstractions and the > > > > > control schemes around them including support for delegation. AFAICS, > > > > > gpu side still seems to have a long way to go (and it's not clear > > > > > whether that's somewhere it will or needs to end up). > > > > > > > > > > > want to have similar functionality as what cgroup is offering but to > > > > > > manage vendor specific resources, what would you suggest as a > > > > > > solution? When you say keeping vendor specific resource regulation > > > > > > inside drm or specific drivers, do you mean we should replicate the > > > > > > cgroup infrastructure there or do you mean either drm or specific > > > > > > driver should query existing hierarchy (such as device or perhaps > > > > > > cpu) for the process organization information? > > > > > > > > > > > > To put the questions in more concrete terms, let say a user wants to > > > > > > expose certain part of a gpu to a particular cgroup similar to the > > > > > > way selective cpu cores are exposed to a cgroup via cpuset, how > > > > > > should we go about enabling such functionality? > > > > > > > > > > Do what the intel driver or bpf is doing? It's not difficult to hook > > > > > into cgroup for identification purposes. > > > > > > > > > > Thanks. > > > > > > > > > > -- > > > > > tejun > > > > > ___ > > > > > amd-gfx mailing list > > > > > amd-gfx@lists.freedesktop.org > > > > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > > > > > > > > > > > > > > > amd-gfx Info Page - freedesktop.org > > > > > lists.freedesktop.org > > > > > To see the collection of prior postings to the list, visit the > > > > > amd-gfx Archives.. Using amd-gfx: To post a message to all the list > > > > > members, send email to amd-gfx@lists.freedesktop.org. You can > > > > > subscribe to the list, or change your existing subscription, in the > > > > > sections below. > > > > > > > > > > ___ > > > > > Intel-gfx mailing list > > > > > intel-...@lists.freedesktop.org > > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
