On Mon, Jun 5, 2017 at 3:07 PM, Marek Olšák <mar...@gmail.com> wrote:
> Hi Aaron,
>
> 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);
--Aaron
>
> Thanks,
> Marek
>
> On Mon, Jun 5, 2017 at 2:32 AM, Aaron Watry <awa...@gmail.com> wrote:
>> The CL CTS queries the max allocation size, and then attempts to
>> allocate buffers of that size. If any of the VRAM is in use, this
>> causes errors in the radeon kernel module.
>>
>> It's a bit of a hack, but experimentally on my system, I can use 3/4
>> of the card's VRAM for a single global/constant buffer allocation given
>> current GUI/compositor use.
>>
>> If there's a way to get the actual amount of free VRAM, I'd love to hear
>> about it.
>>
>> Also, I'm unsure if the radeon kernel module requires all allocated memory
>> to be
>> contiguous, if so, then we'd need to be able to get at that value.. I'm
>> suspecting
>> that's not actually the case.
>>
>> For a 1GB Pitcairn (HD7850) this gets me from the reported clinfo values of:
>> Global memory size 2143076352 (1.996GiB)
>> Max memory allocation 1500153446 (1.397GiB)
>> Max constant buffer size 1500153446 (1.397GiB)
>>
>> To:
>> Global memory size 2143076352 (1.996GiB)
>> Max memory allocation 805306368 (768MiB)
>> Max constant buffer size 805306368 (768MiB)
>>
>> Fixes: OpenCL CTS test/conformance/api/min_max_mem_alloc_size,
>> OpenCL CTS test/conformance/api/min_max_constant_buffer_size
>>
>> Signed-off-by: Aaron Watry <awa...@gmail.com>
>> ---
>> src/gallium/drivers/radeon/r600_pipe_common.c | 17 +++++++++++++++--
>> 1 file changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
>> b/src/gallium/drivers/radeon/r600_pipe_common.c
>> index 2c0cadb030..cdd4062fd3 100644
>> --- a/src/gallium/drivers/radeon/r600_pipe_common.c
>> +++ b/src/gallium/drivers/radeon/r600_pipe_common.c
>> @@ -1144,8 +1144,21 @@ static int r600_get_compute_param(struct pipe_screen
>> *screen,
>> if (ret) {
>> uint64_t *max_mem_alloc_size = ret;
>>
>> - *max_mem_alloc_size = rscreen->info.max_alloc_size;
>> - }
>> + uint64_t max_alloc = rscreen->info.max_alloc_size;
>> +
>> + if (rscreen->info.has_dedicated_vram) {
>> + /* XXX: Hack to prevent system hangs...
>> + * Limit to 3/4 VRAM for any single
>> allocation.
>> + * Prevents:
>> + * radeon: Not enough memory for command
>> submission.
>> + */
>> + *max_mem_alloc_size = MIN2(
>> + rscreen->info.vram_size * 3 / 4,
>> max_alloc
>> + );
>> + } else {
>> + *max_mem_alloc_size = max_alloc;
>> + }
>> + }
>> return sizeof(uint64_t);
>>
>> case PIPE_COMPUTE_CAP_MAX_CLOCK_FREQUENCY:
>> --
>> 2.11.0
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
