| Message ID | 1405531594-25297-1-git-send-email-alexander.deucher@amd.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Am 16.07.2014 19:26, schrieb Alex Deucher: > Now that fallback to gtt is fixed for cpu access, we can > remove this limit. > > Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> > --- > drivers/gpu/drm/radeon/radeon_gem.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c > index fdd189b..07a13c9 100644 > --- a/drivers/gpu/drm/radeon/radeon_gem.c > +++ b/drivers/gpu/drm/radeon/radeon_gem.c > @@ -55,8 +55,11 @@ 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. > + */ > + max_size = rdev->mc.gtt_size; > if (size > max_size) { > DRM_DEBUG("Allocation size %dMb bigger than %ldMb limit\n", > size >> 20, max_size >> 20);
On 17.07.2014 02:26, Alex Deucher wrote: > Now that fallback to gtt is fixed for cpu access, we can > remove this limit. > > Signed-off-by: Alex Deucher <alexander.deucher@amd.com> > --- > drivers/gpu/drm/radeon/radeon_gem.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c > index fdd189b..07a13c9 100644 > --- a/drivers/gpu/drm/radeon/radeon_gem.c > +++ b/drivers/gpu/drm/radeon/radeon_gem.c > @@ -55,8 +55,11 @@ 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. > + */ > + max_size = rdev->mc.gtt_size; > if (size > max_size) { > DRM_DEBUG("Allocation size %dMb bigger than %ldMb limit\n", > size >> 20, max_size >> 20); A BO of size rdev->mc.gtt_size can never actually be bound to GTT, because we have some pinned BOs in there. I think it's a bit disingenuous to let userspace allocate a BO that can never actually be used by the GPU. :) The hack I attached to https://bugs.freedesktop.org/show_bug.cgi?id=78717 has a start for dealing with that. I was running that patch for a while and didn't notice any bad effects from it.
Am 17.07.2014 06:02, schrieb Michel Dänzer: > On 17.07.2014 02:26, Alex Deucher wrote: >> Now that fallback to gtt is fixed for cpu access, we can >> remove this limit. >> >> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> >> --- >> drivers/gpu/drm/radeon/radeon_gem.c | 7 +++++-- >> 1 file changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c >> index fdd189b..07a13c9 100644 >> --- a/drivers/gpu/drm/radeon/radeon_gem.c >> +++ b/drivers/gpu/drm/radeon/radeon_gem.c >> @@ -55,8 +55,11 @@ 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. >> + */ >> + max_size = rdev->mc.gtt_size; >> if (size > max_size) { >> DRM_DEBUG("Allocation size %dMb bigger than %ldMb limit\n", >> size >> 20, max_size >> 20); > A BO of size rdev->mc.gtt_size can never actually be bound to GTT, > because we have some pinned BOs in there. I think it's a bit > disingenuous to let userspace allocate a BO that can never actually be > used by the GPU. :) > > The hack I attached to > https://bugs.freedesktop.org/show_bug.cgi?id=78717 has a start for > dealing with that. I was running that patch for a while and didn't > notice any bad effects from it. Haven't looked at the patch yet, but can't we just go over all existing allocations on PIN and figure out the largest free area and save that value? I mean pinning of GTT memory happens rarely and mostly on system startup. Christian.
On Thu, Jul 17, 2014 at 10:28 AM, Christian König <deathsimple@vodafone.de> wrote: > Am 17.07.2014 06:02, schrieb Michel Dänzer: > >> On 17.07.2014 02:26, Alex Deucher wrote: >>> >>> Now that fallback to gtt is fixed for cpu access, we can >>> remove this limit. >>> >>> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> >>> --- >>> drivers/gpu/drm/radeon/radeon_gem.c | 7 +++++-- >>> 1 file changed, 5 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c >>> b/drivers/gpu/drm/radeon/radeon_gem.c >>> index fdd189b..07a13c9 100644 >>> --- a/drivers/gpu/drm/radeon/radeon_gem.c >>> +++ b/drivers/gpu/drm/radeon/radeon_gem.c >>> @@ -55,8 +55,11 @@ 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. >>> + */ >>> + max_size = rdev->mc.gtt_size; >>> if (size > max_size) { >>> DRM_DEBUG("Allocation size %dMb bigger than %ldMb >>> limit\n", >>> size >> 20, max_size >> 20); >> >> A BO of size rdev->mc.gtt_size can never actually be bound to GTT, >> because we have some pinned BOs in there. I think it's a bit >> disingenuous to let userspace allocate a BO that can never actually be >> used by the GPU. :) >> >> The hack I attached to >> https://bugs.freedesktop.org/show_bug.cgi?id=78717 has a start for >> dealing with that. I was running that patch for a while and didn't >> notice any bad effects from it. > > > Haven't looked at the patch yet, but can't we just go over all existing > allocations on PIN and figure out the largest free area and save that value? > I mean pinning of GTT memory happens rarely and mostly on system startup. yeah, I had the same thought. Alex
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c index fdd189b..07a13c9 100644 --- a/drivers/gpu/drm/radeon/radeon_gem.c +++ b/drivers/gpu/drm/radeon/radeon_gem.c @@ -55,8 +55,11 @@ 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. + */ + max_size = rdev->mc.gtt_size; if (size > max_size) { DRM_DEBUG("Allocation size %dMb bigger than %ldMb limit\n", size >> 20, max_size >> 20);
Now that fallback to gtt is fixed for cpu access, we can remove this limit. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> --- drivers/gpu/drm/radeon/radeon_gem.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)