On 17-03-10 11:32:35, Emil Velikov wrote:
On 10 March 2017 at 01:48, Ben Widawsky <b...@bwidawsk.net> wrote:
The idea behind modifiers like this is that the user of GBM will have
some mechanism to query what properties the hardware supports for its BO
or surface. This information is directly passed in (and stored) so that
the DRI implementation can create an image with the appropriate
attributes.
A getter() will be added later so that the user GBM will be able to
query what modifier should be used.
Only in surface creation, the modifiers are stored until the BO is
actually allocated. In regular buffer allocation, the correct modifier
can (will be, in future patches be chosen at creation time.
v2: Make sure to check if count is non-zero in addition to testing if
calloc fails. (Daniel)
v3: Remove "usage" and "flags" from modifier creation. Requested by
Kristian.
v4: Take advantage of the "INVALID" modifier added by the GET_PLANE2
series.
v5: Don't bother with storing modifiers for gbm_bo_create because that's
a synchronous operation and we can actually select the correct modifier
at create time (done in a later patch) (Jason)
Cc: Kristian Høgsberg <k...@bitplanet.net>
Cc: Jason Ekstrand <ja...@jlekstrand.net>
References (v4):
https://lists.freedesktop.org/archives/intel-gfx/2017-January/116636.html
Signed-off-by: Ben Widawsky <b...@bwidawsk.net>
Reviewed-by: Eric Engestrom <eric.engest...@imgtec.com> (v1)
Acked-by: Daniel Stone <dani...@collabora.com>
---
src/egl/drivers/dri2/platform_drm.c | 19 ++++++++++++---
Worth splitting the patches - patch N+1
src/gbm/backends/dri/gbm_dri.c | 42 ++++++++++++++++++++++++++------
src/gbm/gbm-symbols-check | 2 ++
src/gbm/main/gbm.c | 29 ++++++++++++++++++++--
src/gbm/main/gbm.h | 12 +++++++++
src/gbm/main/gbmint.h | 12 +++++++--
Patch N
src/mesa/drivers/dri/i965/intel_screen.c | 18 ++++++++++++++
Patch N+Y
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -1023,13 +1023,20 @@ free_bo:
static struct gbm_bo *
gbm_dri_bo_create(struct gbm_device *gbm,
uint32_t width, uint32_t height,
- uint32_t format, uint32_t usage)
+ uint32_t format, uint32_t usage,
+ const uint64_t *modifiers,
+ const unsigned int count)
{
struct gbm_dri_device *dri = gbm_dri_device(gbm);
struct gbm_dri_bo *bo;
int dri_format;
unsigned dri_use = 0;
+ /* Callers of this may specify a modifier, or a dri usage, but not both. The
+ * newer modifier interface deprecates the older usage flags.
+ */
+ assert(!(usage && count));
+
Similar to last patch - XOR ?
I don't believe so, I still think NAND is right, but I guess I can't say
indisputably that dri_use == 0 is valid.
if (usage & GBM_BO_USE_WRITE || dri->image == NULL)
return create_dumb(gbm, width, height, format, usage);
@@ -1087,11 +1094,21 @@ gbm_dri_bo_create(struct gbm_device *gbm,
/* Gallium drivers requires shared in order to get the handle/stride */
dri_use |= __DRI_IMAGE_USE_SHARE;
- bo->image =
- dri->image->createImage(dri->screen,
- width, height,
- dri_format, dri_use,
- bo);
+ if (!dri->image || dri->image->base.version < 14 ||
+ !dri->image->createImageWithModifiers) {
+ if (modifiers)
+ fprintf(stderr, "Modifiers specified, but DRI is too old\n");
+
+ bo->image = dri->image->createImage(dri->screen, width, height,
+ dri_format, dri_use, bo);
With the "modifiers or use" above how do we get sane value for dri_use
in this fall-back ?
Seems like things we'll miss/ignore the scanout/curson/linear flags.
Perhaps it's worth simply bailing out ?
Yes, I think you're right. Jason said basically the same thing, but the way
you've presented it, it's more obvious to me that baling out is the right thing
to do.
So I've changed this locally.
Same thing basically for gbm_dri_surface_create()
--- a/src/gbm/gbm-symbols-check
+++ b/src/gbm/gbm-symbols-check
+gbm_bo_create_with_modifiers
+gbm_surface_create_with_modifiers
Thank you :-)
+GBM_EXPORT struct gbm_bo *
+gbm_bo_create_with_modifiers(struct gbm_device *gbm,
+ uint32_t width, uint32_t height,
+ uint32_t format,
+ const uint64_t *modifiers,
+ const unsigned int count)
+{
+ if (width == 0 || height == 0) {
+ errno = EINVAL;
+ return NULL;
+ }
+
Should we validate modifiers and/or count at this level as well ?
Yeah, I suppose that makes sense. I got this change locally.
I honestly think almost no validation should be done at this level so that the
implementation can do whatever weird stuff it wants to do, but there is
precedent for handling some errors.
+GBM_EXPORT struct gbm_surface *
+gbm_surface_create_with_modifiers(struct gbm_device *gbm,
+ uint32_t width, uint32_t height,
+ uint32_t format,
+ const uint64_t *modifiers,
+ const unsigned int count)
+{
Ditto ? What happens if we feed zero width/height ?
Worth adding a note, even if things are expected to blow up ?
I don't know. I copied gbm_surface_create() which doesn't check width and
height, but I did add the modifier/count check.
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
+static uint64_t
+select_best_modifier(struct gen_device_info *devinfo,
+ const uint64_t *modifiers,
+ const unsigned count)
+{
+ return DRM_FORMAT_MOD_INVALID;
Worth adding a note why any combination of modifiers is ignored ?
-Emil
Originally I was attempting to land the whole series at once, so it didn't
really matter. It's added in later patches. I can add that information to the
commit message and comment.
--
Ben Widawsky, Intel Open Source Technology Center
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
