[Mesa-dev] [PATCH 2/2] RFC: radeon/compute: Limit allocations for VRAM-based chips to 3/4 VRAM

[Marek Olšák]

On Mon, Jun 12, 2017 at 5:19 AM, Michel Dänzer <michel at daenzer.net> wrote:
> On 10/06/17 12:43 AM, Aaron Watry wrote:
>> On Wed, Jun 7, 2017 at 11:12 PM, Aaron Watry <awatry at gmail.com> wrote:
>>> On Wed, Jun 7, 2017 at 9:15 PM, Michel Dänzer <michel at daenzer.net> wrote:
>>>> On 08/06/17 03:42 AM, Marek Olšák wrote:
>>>>> On Wed, Jun 7, 2017 at 4:10 PM, Aaron Watry <awatry at gmail.com> wrote:
>>>>>> On Mon, Jun 5, 2017 at 3:07 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>>>>>>
>>>>>>> Can you make the change in radeon_drm_winsys.c instead?
>>>>>>
>>>>>> Something like the following?
>>>>>>
>>>>>> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
>>>>>> b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
>>>>>> index a485615ae4..44948f49ef 100644
>>>>>> --- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
>>>>>> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
>>>>>> @@ -365,6 +365,8 @@ static bool do_winsys_init(struct radeon_drm_winsys *ws)
>>>>>>      /* Radeon allocates all buffers as contigous, which makes large allocations
>>>>>>       * unlikely to succeed. */
>>>>>>      ws->info.max_alloc_size = MAX2(ws->info.vram_size,
>>>>>> ws->info.gart_size) * 0.7;
>>>>>> +    if (ws->info.has_dedicated_vram)
>>>>>> +        ws->info.max_alloc_size = MIN2(ws->info.vram_size * 0.7,
>>>>>> ws->info.max_alloc_size);
>>>>>>      if (ws->info.drm_minor < 40)
>>>>>>          ws->info.max_alloc_size = MIN2(ws->info.max_alloc_size, 256*1024*1024);
>>>>>
>>>>> Yes, feel free to push that.
>>>>
>>>> That also affects PIPE_CAP_MAX_TEXTURE_BUFFER_SIZE, is that intended?
>>>
>>> Not necessarily.
>>>
>>> Part of the reason that I had originally put this in
>>> r600_pipe_common.c under the compute params was that I didn't feel
>>> comfortable changing this for all workload types. There's evidence
>>> that implies that the closed-source AMD CL runtime limits global
>>> allocations to either 256MB or 1/4 VRAM (on a 1GB card), so 70% of the
>>> max of GART/VRAM seems a bit high for us to report. I'll probably
>>> check around a bit and see what the prevailing limits seem to be and
>>> if lowering the absolute max might make sense here (for compute loads
>>> only), as a failure to allocate the requested amount of memory seems
>>> to result in system hangs shortly thereafter, and I'd like to get the
>>> frequency of those occurrences down a bit.
>>
>> At least in Windows 10 using the AMD binary CL runtime, it reports
>> global memory size of 2GB and max allocation of 1GB for the 1GB card
>> that I've got.  Whether that's being calculated as max allocation =
>> VRAM-size, or 50% of global memory size is an unknown. I'm not sure if
>> you can easily adjust the gart size in windows. So my original theory
>> of 1/4 VRAM seems to be limited to other cards or older drivers/OSes.
>>
>> Given that Marek/Nicolai want to stick this in radeon_drm_winsys.c,
>> I'm ok with putting it there.  I think it still makes sense to limit
>> the max allocation to a percentage of VRAM when the card has its own
>> memory available for the reasons already mentioned by Nicolai. Whether
>> 70% is a good number is another question, but one thing at a time.
>>
>> Any objections Michel, or were you just raising the point that it
>> affected the texture allocation sizes just to make sure we were aware?
>
> Right, just wanted to make sure everybody's aware.

GL_MAX_TEXTURE_BUFFER_SIZE can be as low as 64K.

Marek