[igt-dev] [PATCH i-g-t v5 3/4] lib/i915/intel_memory_region: Add lib to manage memory regions
Zbigniew Kempczyński
zbigniew.kempczynski at intel.com
Fri Nov 22 09:33:07 UTC 2019
On Fri, Nov 22, 2019 at 09:11:46AM +0000, Chris Wilson wrote:
> > +const struct intel_memory_region intel_memory_regions[] = {
> > + { "SMEM", LOCAL_I915_SYSTEM_MEMORY, 0 },
>
> I love how the friendly names are so terse and do not follow the api /s
>
> > + { "LMEM", LOCAL_I915_DEVICE_MEMORY, 0 },
> > + { "STLN", LOCAL_I915_STOLEN_MEMORY, 0 },
> > + { NULL, 0, 0 },
> > +};
> > +
> > +const char *memory_region_name(uint32_t region) {
> > + uint32_t type;
> > +
> > + type = MEMORY_TYPE_FROM_REGION(region);
>
> We will never end up with garbage here, but we are so polite in our
> testing.
If you have better idea I'll fix that.
>
> > +
> > + return intel_memory_regions[type].region_name;
> > +}
> > +/**
> > + * gem_get_batch_size:
> > + * @fd: open i915 drm file descriptor
> > + * @region: region in which we want to create a batch
> > + *
> > + * FIXME: Currently function assumes we have 64K on DEVICE and 4K
> > + * on SYSTEM memory. To be fixed after memory region page size detection
> > + * patch will be merged.
> > + */
> > +uint32_t gem_get_batch_size(int fd, uint32_t region)
> > +{
> > + return IS_DEVICE_MEMORY_REGION(region) ? SZ_64K : SZ_4K;
> > +}
> > +
> > +static bool __try_gem_create_in_region(int fd, uint32_t region)
> > +{
> > + uint32_t size, handle;
> > + int ret;
> > +
> > + size = gem_get_batch_size(fd, region);
>
> size=1 will always be correct, that has now been enshrined in the ABI.
Should I change it or region "page size" is acceptable?
>
> > + handle = gem_create(fd, size);
> > + ret = gem_migrate_to_memory_region(fd, handle, region);
>
> Migrate is definitely not supported in the first wave of landings;
> memory placement will be a construction time property with possible
> later extension to runtime.
If I would have gem_create_ext() I would definitely use it. Unfortunately
only mechanism I know at the moment to place BO in memory region is
to migrate it. Is anything I missed? Will we have gem_create_ext() with
memory region as an argument?
>
> > +
> > + gem_close(fd, handle);
> > +
> > + return !ret;
> > +}
> > +
> > +static struct local_i915_query_memory_region_info *__probe_regions(int fd)
> > +{
> > + struct local_i915_query_memory_region_info *query_info;
> > + uint32_t length = sizeof(*query_info);
> > + uint32_t *regions = NULL;
> > + int max_regions = INTEL_MEMORY_TYPE_SHIFT;
> > + int num_regions = 0;
> > +
> > + for (int i = 0; intel_memory_regions[i].region_name; i++) {
> > + uint8_t type;
> > +
> > + /* We're not interested of other memory region types */
> > + type = intel_memory_regions[i].memory_type;
> > + if (type != LOCAL_I915_SYSTEM_MEMORY &&
> > + type != LOCAL_I915_DEVICE_MEMORY)
> > + continue;
> > +
> > + for (int instance = 0; instance <= max_regions; instance++) {
> > + uint32_t region;
> > + int exists;
> > +
> > + region = INTEL_MEMORY_REGION_ID(type, instance);
> > + igt_debug("Probing memory region: %08x\n", region);
> > + exists = __try_gem_create_in_region(fd, region);
> > + if (!exists)
> > + break;
> > +
> > + igt_debug("Region %08x exists\n", region);
> > + regions = realloc(regions, (num_regions + 1) *
> > + sizeof(uint32_t));
> > + igt_assert(regions);
> > + regions[num_regions++] = region;
> > + }
> > + }
> > +
> > + if (!num_regions)
> > + return NULL;
> > +
> > + length += sizeof(struct local_i915_memory_region_info) * num_regions;
> > + query_info = calloc(1, length);
> > + igt_assert(query_info);
> > +
> > + /* Prepare query_info structure with regions id filled */
> > + for (int i = 0; i < num_regions; i++) {
> > + query_info->regions[i].id = regions[i];
> > + query_info->regions[i].size = 0;
> > + }
> > + free(regions);
> > + query_info->num_regions = num_regions;
> > +
> > + return query_info;
> > +}
> > +
> > +/**
> > + * gem_query_memory_regions:
> > + * @fd: open i915 drm file descriptor
> > + *
> > + * This function wraps query mechanism for memory regions. If there's
> > + * no i915_query probe memory regions and return same structure as from query.
> > + *
> > + * Returns: Filled struct with available memory regions. Allocates structure
> > + * which must by freed by caller.
> > + */
> > +struct local_i915_query_memory_region_info *gem_query_memory_regions(int fd)
> > +{
> > + struct drm_i915_query_item item;
> > + struct local_i915_query_memory_region_info *query_info;
> > + int ret;
> > +
> > + memset(&item, 0, sizeof(item));
> > + item.query_id = LOCAL_I915_QUERY_MEMREGION_INFO;
> > +
> > + ret = __i915_query_item(fd, &item);
> > + if (!ret) {
> > + query_info = calloc(1, item.length);
> > + igt_assert(query_info);
> > +
> > + item.data_ptr = to_user_pointer(query_info);
> > + __i915_query_item(fd, &item);
> > +
> > + return query_info;
> > + }
> > +
> > + /* Fallback, there's no memregion i915_query supported. Try probe(). */
> > + query_info = __probe_regions(fd);
>
> Oh, we will not have memory regions without a query. If anything we will
> get memory regions described before you can make a choice.
Unfortunately after your comment on previous series I concluded after first
memory region patches landing we would support them without query (current
patches doesn't support them, thus this fallback).
>
> > + igt_assert(query_info);
> > +
> > + return query_info;
> > +}
> > +
> > +/**
> > + * gem_get_lmem_region_count:
> > + * @fd: open i915 drm file descriptor
> > + *
> > + * Helper function to check how many lmem regions are available on device.
> > + *
> > + * Returns: Number of found lmem regions.
> > + */
> > +uint8_t gem_get_lmem_region_count(int fd)
> > +{
> > + struct local_i915_query_memory_region_info *query_info;
> > + uint8_t num_regions;
> > + uint8_t lmem_regions = 0;
> > +
> > + query_info = gem_query_memory_regions(fd);
> > + num_regions = query_info->num_regions;
> > +
> > + for (int i = 0; i < num_regions; i++) {
> > + if (IS_DEVICE_MEMORY_REGION(query_info->regions[i].id))
> > + lmem_regions += 1;
> > + }
> > + free(query_info);
>
> Meh. Didn't need the heap.
You're suggesting doing allocation in lmem regions until it fails?
A lot of ioctl() will be called in this case.
>
> > + return lmem_regions;
> > +}
> > +
> > +/**
> > + * gem_has_lmem:
> > + * @fd: open i915 drm file descriptor
> > + *
> > + * Helper function to check if lmem is available on device.
> > + *
> > + * Returns: True if at least one lmem region was found.
> > + */
> > +bool gem_has_lmem(int fd)
> > +{
> > + return gem_get_lmem_region_count(fd) > 0;
>
> That seems even more of a waste of heap, as above.
>
> > +}
> > +
> > +/**
> > + * gem_query_has_memory_region:
> > + * @query_info: query result of memory regions
> > + * @region: region existance to check inside @query_info regions
> > + *
> > + * This function check existence of region in @query_info
> > + *
> > + * Returns: true if memory region was found. Otherwise false.
> > + */
> > +bool gem_query_has_memory_region(struct local_i915_query_memory_region_info *query_info,
>
> Remind me to have words with the naming committee.
>
> The rest is for an interface that has yet to be seen and discussed, so
> shelving for later.
> -Chris
To be ownest I don't know what's wrong with this function name.
If you have better candidate you're welcome.
Zbigniew
More information about the igt-dev
mailing list