From: Jani Nikula <jani.nikula@linux.intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>,
Matt Roper <matthew.d.roper@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [Intel-xe] [PATCH 1/3] drm/xe: Use packed bitfields for xe->info feature flags
Date: Tue, 11 Apr 2023 10:56:37 +0300 [thread overview]
Message-ID: <87leiyetsa.fsf@intel.com> (raw)
In-Reply-To: <20230411070133.byyciicbo4a7z3qt@ldmartin-desk2.lan>
On Tue, 11 Apr 2023, Lucas De Marchi <lucas.demarchi@intel.com> wrote:
> On Mon, Apr 10, 2023 at 11:39:08AM -0700, Matt Roper wrote:
>>Replace 'bool' fields with single bits to allow the various device
>>feature flags to pack more tightly.
>
> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
>
> but a digression:
>
> for structs like the descriptors in xe_pci.c, this justification is
> enough as we will be maintaining several of those as they extend to
> each platform. Also the access to struct members is contained in
> one place.
>
> However this reasoning can't be generalized to structs like xe_device,
> that has one allocated per device. The gain should be very minimal if
> any at all.
>
> 1) Each place accessing one of these fields will have more
> instructions generated to use the right bit although in most cases
> the compiler should swap a cmpb with testb since we are likely just
> checking if the feature is available or not.
>
> 2) It also limits the ability to pass them by address.
>
> 3) We also need to be careful when changing
> bool -> u8 as they don't have the same semantics in cases like
> `b = true; b++;`, which may not be obvious in some cases.
>
> for (1), the pro/con should be really small, (2) we should get a
> compiler error if we tried. But for (3)... we need to check all the
> fields we are converting to make sure this doesn't introduce bugs. I'm
> on the fence on the need for this change, but I'm ok with it. I double
> checked all the members in the struct and didn't find use cases that
> would introduce a bug, hence my r-b above.
bloat-o-meter results with both might be interesting, for code and
data. Does the data saving matter if we bloat code more?
BR,
Jani.
>
>
> Lucas De Marchi
>
>>
>>Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
>>---
>> drivers/gpu/drm/xe/xe_device_types.h | 21 +++++++++++----------
>> 1 file changed, 11 insertions(+), 10 deletions(-)
>>
>>diff --git a/drivers/gpu/drm/xe/xe_device_types.h b/drivers/gpu/drm/xe/xe_device_types.h
>>index f5399b284e3b..9ce6e348dd29 100644
>>--- a/drivers/gpu/drm/xe/xe_device_types.h
>>+++ b/drivers/gpu/drm/xe/xe_device_types.h
>>@@ -67,8 +67,6 @@ struct xe_device {
>> u32 media_verx100;
>> /** @mem_region_mask: mask of valid memory regions */
>> u32 mem_region_mask;
>>- /** @is_dgfx: is discrete device */
>>- bool is_dgfx;
>> /** @platform: XE platform enum */
>> enum xe_platform platform;
>> /** @subplatform: XE subplatform enum */
>>@@ -87,22 +85,25 @@ struct xe_device {
>> u8 tile_count;
>> /** @vm_max_level: Max VM level */
>> u8 vm_max_level;
>>+
>>+ /** @is_dgfx: is discrete device */
>>+ u8 is_dgfx:1;
>> /** @supports_usm: Supports unified shared memory */
>>- bool supports_usm;
>>+ u8 supports_usm:1;
>> /** @has_asid: Has address space ID */
>>- bool has_asid;
>>+ u8 has_asid:1;
>> /** @enable_guc: GuC submission enabled */
>>- bool enable_guc;
>>+ u8 enable_guc:1;
>> /** @has_flat_ccs: Whether flat CCS metadata is used */
>>- bool has_flat_ccs;
>>+ u8 has_flat_ccs:1;
>> /** @has_4tile: Whether tile-4 tiling is supported */
>>- bool has_4tile;
>>+ u8 has_4tile:1;
>> /** @has_range_tlb_invalidation: Has range based TLB invalidations */
>>- bool has_range_tlb_invalidation;
>>+ u8 has_range_tlb_invalidation:1;
>> /** @has_link_copy_engines: Whether the platform has link copy engines */
>>- bool has_link_copy_engine;
>>+ u8 has_link_copy_engine:1;
>> /** @enable_display: display enabled */
>>- bool enable_display;
>>+ u8 enable_display:1;
>>
>> #if IS_ENABLED(CONFIG_DRM_XE_DISPLAY)
>> struct xe_device_display_info {
>>--
>>2.39.2
>>
--
Jani Nikula, Intel Open Source Graphics Center
next prev parent reply other threads:[~2023-04-11 7:56 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-10 18:39 [Intel-xe] [PATCH 1/3] drm/xe: Use packed bitfields for xe->info feature flags Matt Roper
2023-04-10 18:39 ` [Intel-xe] [PATCH 2/3] drm/xe: Track whether platform has LLC Matt Roper
2023-04-11 7:00 ` Lucas De Marchi
2023-04-10 18:39 ` [Intel-xe] [PATCH 3/3] drm/xe: Only request PCODE_WRITE_MIN_FREQ_TABLE on LLC platforms Matt Roper
2023-04-11 7:01 ` Lucas De Marchi
2023-04-10 19:31 ` [Intel-xe] ✓ CI.Patch_applied: success for series starting with [1/3] drm/xe: Use packed bitfields for xe->info feature flags Patchwork
2023-04-10 19:32 ` [Intel-xe] ✓ CI.KUnit: " Patchwork
2023-04-10 19:36 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-04-10 19:56 ` [Intel-xe] ○ CI.BAT: info " Patchwork
2023-04-10 21:58 ` [Intel-xe] [PATCH 1/3] " Matthew Brost
2023-04-11 7:01 ` Lucas De Marchi
2023-04-11 7:56 ` Jani Nikula [this message]
2023-04-11 15:22 ` Matt Roper
2023-04-11 17:01 ` Lucas De Marchi
2023-04-11 17:27 ` Matt Roper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87leiyetsa.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=matthew.d.roper@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.