On 18.07.2014 12:26, Alex Deucher wrote: > On Thu, Jul 17, 2014 at 8:41 PM, Michel Dänzer <michel@xxxxxxxxxxx> wrote: >> On 18.07.2014 01:29, Alex Deucher wrote: >>> @@ -55,10 +55,13 @@ int radeon_gem_object_create(struct radeon_device *rdev, int size, >>> alignment = PAGE_SIZE; >>> } >>> >>> - /* maximun bo size is the minimun btw visible vram and gtt size */ >>> - max_size = min(rdev->mc.visible_vram_size, rdev->mc.gtt_size); >>> + /* Maximum bo size is the gtt size since we use the gtt to handle >>> + * vram to system pool migrations. We could probably remove this >>> + * check altogether with a little additional work. >>> + */ >> >> This comment needs updating: it's not the full GTT size anymore, and how >> could we remove this check? > > I'll update it. We could remove it if we added support for breaking > down vram <-> system transfers into smaller operations. E.g., if the > available vram size was twice the size of the available gtt space, we > could transfer the first half, then update the gart table and transfer > the second half. Right, OTOH I suspect it's even less likely that BOs of (almost) the size of VRAM can actually be used in VRAM, because e.g. scanout buffers are pinned anywhere in VRAM. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
