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. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
