From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES
Date: Mon, 14 Mar 2022 10:50:28 -0700 [thread overview]
Message-ID: <87lexcpgnv.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <025a284f-a1fc-3f7a-12eb-d5a4029e3393@linux.intel.com>
On Mon, 14 Mar 2022 08:35:17 -0700, Tvrtko Ursulin wrote:
>
> >> Alternatively, all other uapi uses struct i915_engine_class_instance to
> >> address engines which uses u16:u16.
> >>
> >> How ugly it is to stuff a struct into u32 flags is the question... But you
> >> could at least use u16:u16 for consistency. Unless you wanted to leave some
> >> bits free for the future?
> > Originally when I wrote this I was wanting to leave space in case it was
> > ever needed. I'm not particularly for or against keeping the space now.
>
> Yes, shrug... Neither I can't guess if we are ever likely to hit a problem
> by having fewer bits for class:instance here compared to other uapi, or if
> stuffing struct i915_engine_class_instance into flags would just be too
> ugly. I mean there is option to define a new struct and not use flags at
> all but that's probably to complicated for what it is.
>
> Anyone else with an opinion? Consistency or should be fine even like it is?
Consistency. I'd prefer to stuff struct i915_engine_class_instance into
flags, fwiw.
WARNING: multiple messages have this Message-ID (diff)
From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org,
Matt Atwood <matthew.s.atwood@intel.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES
Date: Mon, 14 Mar 2022 10:50:28 -0700 [thread overview]
Message-ID: <87lexcpgnv.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <025a284f-a1fc-3f7a-12eb-d5a4029e3393@linux.intel.com>
On Mon, 14 Mar 2022 08:35:17 -0700, Tvrtko Ursulin wrote:
>
> >> Alternatively, all other uapi uses struct i915_engine_class_instance to
> >> address engines which uses u16:u16.
> >>
> >> How ugly it is to stuff a struct into u32 flags is the question... But you
> >> could at least use u16:u16 for consistency. Unless you wanted to leave some
> >> bits free for the future?
> > Originally when I wrote this I was wanting to leave space in case it was
> > ever needed. I'm not particularly for or against keeping the space now.
>
> Yes, shrug... Neither I can't guess if we are ever likely to hit a problem
> by having fewer bits for class:instance here compared to other uapi, or if
> stuffing struct i915_engine_class_instance into flags would just be too
> ugly. I mean there is option to define a new struct and not use flags at
> all but that's probably to complicated for what it is.
>
> Anyone else with an opinion? Consistency or should be fine even like it is?
Consistency. I'd prefer to stuff struct i915_engine_class_instance into
flags, fwiw.
next prev parent reply other threads:[~2022-03-14 17:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-10 5:18 [Intel-gfx] [PATCH] drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES Matt Atwood
2022-03-10 5:18 ` Matt Atwood
2022-03-10 5:47 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES (rev2) Patchwork
2022-03-10 6:19 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-03-10 11:45 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-03-10 12:26 ` [Intel-gfx] [PATCH] drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES Tvrtko Ursulin
2022-03-12 4:16 ` Matt Atwood
2022-03-14 15:35 ` Tvrtko Ursulin
2022-03-14 17:50 ` Dixit, Ashutosh [this message]
2022-03-14 17:50 ` Dixit, Ashutosh
2022-03-16 11:30 ` Joonas Lahtinen
-- strict thread matches above, loose matches on Subject: below --
2022-03-16 22:49 Matt Atwood
2022-03-25 23:03 ` Francisco Jerez
2022-03-28 8:44 ` Tvrtko Ursulin
2022-03-28 16:01 ` Matt Roper
2022-03-28 16:01 ` Matt Roper
2022-03-10 0:34 Matt Atwood
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=87lexcpgnv.wl-ashutosh.dixit@intel.com \
--to=ashutosh.dixit@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=tvrtko.ursulin@linux.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.