[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mesa3d-dev
Subject:    Re: [Mesa-dev] [PATCH] i965: Deny persistent mappings of incoherent GTT mmaps
From:       Lionel Landwerlin <lionel.g.landwerlin () intel ! com>
Date:       2018-08-31 12:07:06
Message-ID: 77fcf0e7-126b-758a-5394-327919151664 () intel ! com
[Download RAW message or body]

On 31/08/2018 12:43, Chris Wilson wrote:
> Quoting Lionel Landwerlin (2018-08-31 12:32:23)
>> On 31/08/2018 12:22, Chris Wilson wrote:
>>> Quoting Lionel Landwerlin (2018-08-31 12:16:19)
>>>> We would need a fairly recent kernel (drm-tip?) to test this in CI.
>>> Unpatched mesa, assumes all is fine.
>>> Post-patch mesa, assumes all is broken.
>>>
>>> So we can quickly see if anything actually fails if a persistent GGTT
>>> mmap is rejected. Which is the important part for determining if such
>>> exclusion will harm anyone. The problem is then is the risk of
>>> corruption worth keeping it around.
>>>
>>>> I can't see any issue with this because we always have the meta path as
>>>> a fallback for tiled buffers.
>>> I'm worried if the mmap actually leaks through to glMapBufferRange with
>>> say GL_MAP_PERSISTENT_BIT. Hmm, maybe that's all ok so long at the
>>> client flushes are explicit.
>>
>> As far as I can tell, buffers are linear, so brw_bo_map() wouldn't even
>> try to map in gtt at first.
>>
>> Then brw_bo_map_wc() would assert if it failed.
>>
>> So we're fine? :)
> I like that plan. Not having to rely on GGTT will save a lot of
> headaches.
> -Chris
>
Maybe brw_bo_map() needs to be updated a bit to make that clear.

Ken: does this look okay with you?


-

Lionel

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[prev in list] [next in list] [prev in thread] [next in thread]