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

[Aaron Watry]

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?

--Aaron

>
> --Aaron
>
>
>
>> --
>> Earthling Michel Dänzer               |               http://www.amd.com
>> Libre software enthusiast             |             Mesa and X developer