Am 24.04.19 um 14:05 schrieb Thomas Zimmermann:
> Hi Christian,
>
> Am 24.04.19 um 13:48 schrieb Thomas Zimmermann:
>> +
>> +/*
>> + * Helpers for struct ttm_bo_driver
>> + */
>> +
>> +static bool drm_is_gem_vram(struct ttm_buffer_object *bo)
>> +{
>> + return (bo->destroy == ttm_buffer_object_destroy);
>> +}
>> +
>> +/**
>> + * drm_gem_vram_bo_driver_evict_flags() - \
>> + Implements &struct ttm_bo_driver.evict_flags
>> + * @bo: TTM buffer object. Refers to &struct drm_gem_vram_object.bo
>> + * @pl: TTM placement information.
>> + */
>> +void drm_gem_vram_bo_driver_evict_flags(struct ttm_buffer_object *bo,
>> + struct ttm_placement *pl)
>> +{
>> + struct drm_gem_vram_object *gbo;
>> +
>> + /* TTM may pass BOs that are not GEM VRAM BOs. */
>> + if (!drm_is_gem_vram(bo))
>> + return;
>> +
>> + gbo = drm_gem_vram_of_bo(bo);
>> + drm_gem_vram_placement(gbo, TTM_PL_FLAG_SYSTEM);
>> + *pl = gbo->placement;
>> +}
> For drm_is_gem_vram(), I'm not quite sure what else to test for. So
> there are still a few things I'd like to discuss.
>
> 1) If this test is about the placement flags, then it's unrelated to
> the actual DRM driver. All buffers of type |struct drm_gem_vram_object|
> share the same placement flags.
>
> 2) I tested the code to work with ast and mgag200.
>
> 3) If this test is really about individual instances of each DRM
> driver, then the current implementations are already broken. In this
> scenario TTM should sort out BOs with a BO device different from the one
> that triggered the eviction process; or pass the original BO device to
> the evict_flags callback, so we can sort out buffers here.
Just go ahead with the current approach for now. It could be that we see
fallout, but that is really unlikely.
Christian.
>
> Best regards
> Thomas
>
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
