On Mon, Jun 12, 2017 at 5:19 AM, Michel Dänzer <mic...@daenzer.net> wrote: > On 10/06/17 12:43 AM, Aaron Watry wrote: >> On Wed, Jun 7, 2017 at 11:12 PM, Aaron Watry <awa...@gmail.com> wrote: >>> On Wed, Jun 7, 2017 at 9:15 PM, Michel Dänzer <mic...@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 <awa...@gmail.com> wrote: >>>>>> On Mon, Jun 5, 2017 at 3:07 PM, Marek Olšák <mar...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
