+ Abdiel/intel-gfx
Quoting Joonas Lahtinen (2019-08-14 15:46:01)
> Quoting Chris Wilson (2019-08-14 13:31:10)
> > Quoting Lukasz Kalamarz (2019-08-14 11:21:38)
> > > +/**
> > > + * gem_get_page_size:
> > > + * @fd: open i915 drm file descriptor
> > > + * @mem_region_type: used memory_region type
> > > + *
> > > + * With introduction of LMEM we observe different page sizes for those
> > > two
> > > + * memory regions. Without this helper function we may be prone to
> > > forget
> > > + * about setting proper page size.
> > > + */
> > > +uint32_t gem_get_batch_size(int fd, uint8_t mem_region_type)
> > > +{
> > > + return (mem_region_type == LOCAL_I915_DEVICE_MEMORY) ? 65536 :
> > > 4096;
> >
> > You have to be kidding me. This, this constitutes a forward thinking uAPI?
>
> We should be just fine requesting the minimum BO size we need, letting the KMD
> round the sizes up and reading back the created BO size.
>
> (Now that the regression has been fixed, too :) )
>
> So the code logic needs to be updated to follow that.
On a second thought we may be better off rounding the backing storage
size up transparently.
I guess the prime question is why would the userspace/IGT care for
actual backing storage size?
Abdiel/Matt, how painful would it be to round the backing storage size
up, irrespective of the BO size?
Regards, Joonas
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
