From: "Dieter Nützel" <Dieter-0hun7QTegEsDD4udEopG9Q@public.gmane.org>
To: "Deucher, Alexander" <Alexander.Deucher-5C7GfCeVMHo@public.gmane.org>
Cc: "Alex Deucher"
<alexdeucher-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
mesa-dev-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
"Michel Dänzer" <michel-otUistvHUpPR7s880joybQ@public.gmane.org>,
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Subject: Re: [Mesa-dev] [PATCH] drm/radeon: Fix vram_size/visible values in DRM_RADEON_GEM_INFO ioctl
Date: Tue, 31 Jan 2017 22:08:19 +0100 [thread overview]
Message-ID: <0979879cc40944c65d5a5b8f9bcae197@nuetzel-hh.de> (raw)
In-Reply-To: <BN6PR12MB16528D1DF5184C0A29572C04F74A0-/b2+HYfkarQqUD6E6FAiowdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
Am 31.01.2017 16:43, schrieb Deucher, Alexander:
>> -----Original Message-----
>> From: amd-gfx [mailto:amd-gfx-bounces@lists.freedesktop.org] On Behalf
>> Of Dieter Nützel
>> Sent: Tuesday, January 31, 2017 6:25 AM
>> To: Michel Dänzer
>> Cc: Alex Deucher; mesa-dev@lists.freedesktop.org; amd-
>> gfx@lists.freedesktop.org
>> Subject: Re: [Mesa-dev] [PATCH] drm/radeon: Fix vram_size/visible
>> values in
>> DRM_RADEON_GEM_INFO ioctl
>>
>> Hello Michel,
>>
>> as this is for radeon, do you think this could/should fix
>> the wrong reported VRAM size with Unigine_Heaven/-Valley, too?
>> Maybe speed things up? ;-)
>>
>> Unigine_Valley-1.0
>>
>> GPU: Unknown GPU x1
>> System memory: 24102 MB
>> Video memory: 256 MB
>> Sync threads: 7
>> Async threads: 8
>>
>> I'll try patching openSUSE Kernel:stable 4.9.6-2 with this
>> and maybe this could then go into 4.10-rc7 'cause it is a
>> bugfix. - Alex?
>
> This patch just fixes the case of the HUD reporting the wrong amount
> of visible vram. Most 3D apps just default to 256MB if they don't
> know how much vram is. The problem is GL never provided a core way to
> determine how much vram is available on a GPU so lots of vendor
> specific extensions and driver specific methods popped up to address
> this.
>
> Alex
Ah, no hurry then.
Thanks for clarification.
Dieter
>> Greetings,
>> Dieter
>>
>> Am 31.01.2017 07:54, schrieb Michel Dänzer:
>> > From: Michel Dänzer <michel.daenzer@amd.com>
>> >
>> > vram_size is supposed to be the total amount of VRAM that can be used
>> > by
>> > userspace, which corresponds to the TTM VRAM manager size (which is
>> > normally the full amount of VRAM, but can be just the visible VRAM when
>> > DMA can't be used for BO migration for some reason).
>> >
>> > The above was incorrectly used for vram_visible before, resulting in
>> > generally too large values being reported.
>> >
>> > Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
>> > ---
>> > drivers/gpu/drm/radeon/radeon_drv.c | 3 ++-
>> > drivers/gpu/drm/radeon/radeon_gem.c | 4 ++--
>> > 2 files changed, 4 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
>> > b/drivers/gpu/drm/radeon/radeon_drv.c
>> > index a252bc407aa2..88c41d43ec3d 100644
>> > --- a/drivers/gpu/drm/radeon/radeon_drv.c
>> > +++ b/drivers/gpu/drm/radeon/radeon_drv.c
>> > @@ -97,9 +97,10 @@
>> > * 2.46.0 - Add PFP_SYNC_ME support on evergreen
>> > * 2.47.0 - Add UVD_NO_OP register support
>> > * 2.48.0 - TA_CS_BC_BASE_ADDR allowed on SI
>> > + * 2.49.0 - DRM_RADEON_GEM_INFO ioctl returns correct
>> > vram_size/visible values
>> > */
>> > #define KMS_DRIVER_MAJOR 2
>> > -#define KMS_DRIVER_MINOR 48
>> > +#define KMS_DRIVER_MINOR 49
>> > #define KMS_DRIVER_PATCHLEVEL 0
>> > int radeon_driver_load_kms(struct drm_device *dev, unsigned long
>> > flags);
>> > int radeon_driver_unload_kms(struct drm_device *dev);
>> > diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
>> > b/drivers/gpu/drm/radeon/radeon_gem.c
>> > index 0bcffd8a7bd3..96683f5b2b1b 100644
>> > --- a/drivers/gpu/drm/radeon/radeon_gem.c
>> > +++ b/drivers/gpu/drm/radeon/radeon_gem.c
>> > @@ -220,8 +220,8 @@ int radeon_gem_info_ioctl(struct drm_device *dev,
>> > void *data,
>> >
>> > man = &rdev->mman.bdev.man[TTM_PL_VRAM];
>> >
>> > - args->vram_size = rdev->mc.real_vram_size;
>> > - args->vram_visible = (u64)man->size << PAGE_SHIFT;
>> > + args->vram_size = (u64)man->size << PAGE_SHIFT;
>> > + args->vram_visible = rdev->mc.visible_vram_size;
>> > args->vram_visible -= rdev->vram_pin_size;
>> > args->gart_size = rdev->mc.gtt_size;
>> > args->gart_size -= rdev->gart_pin_size;
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
next prev parent reply other threads:[~2017-01-31 21:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-31 6:54 [PATCH] drm/radeon: Fix vram_size/visible values in DRM_RADEON_GEM_INFO ioctl Michel Dänzer
[not found] ` <20170131065414.2434-1-michel-otUistvHUpPR7s880joybQ@public.gmane.org>
2017-01-31 6:54 ` [PATCH] winsys/radeon: Allow visible VRAM size > 256MB with kernel driver >= 2.49 Michel Dänzer
[not found] ` <20170131065414.2434-2-michel-otUistvHUpPR7s880joybQ@public.gmane.org>
2017-01-31 9:12 ` Samuel Pitoiset
2017-01-31 11:44 ` Nicolai Hähnle
2017-01-31 15:30 ` Deucher, Alexander
2017-01-31 9:09 ` [PATCH] drm/radeon: Fix vram_size/visible values in DRM_RADEON_GEM_INFO ioctl Christian König
2017-01-31 15:30 ` Deucher, Alexander
2017-01-31 11:24 ` Dieter Nützel
[not found] ` <5abbe0dcb709f4624fa52f32d9e3e3d5-0hun7QTegEsDD4udEopG9Q@public.gmane.org>
2017-01-31 15:43 ` [Mesa-dev] " Deucher, Alexander
[not found] ` <BN6PR12MB16528D1DF5184C0A29572C04F74A0-/b2+HYfkarQqUD6E6FAiowdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2017-01-31 21:08 ` Dieter Nützel [this message]
2017-01-31 22:06 ` Emil Velikov
[not found] ` <CACvgo50tFrVg+vq=Lt+5p-GYb9v+M-jRVq66rLAENFn5yoPWDA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-01-31 22:23 ` [Mesa-dev] " Alex Deucher
[not found] ` <CADnq5_MA5NNZ=9T_U7=GG-n-AHs+VxtwksSE6v=9DSAgyZk=Xw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-02-01 19:43 ` Marek Olšák
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0979879cc40944c65d5a5b8f9bcae197@nuetzel-hh.de \
--to=dieter-0hun7qtegesdd4udeopg9q@public.gmane.org \
--cc=Alexander.Deucher-5C7GfCeVMHo@public.gmane.org \
--cc=alexdeucher-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=mesa-dev-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=michel-otUistvHUpPR7s880joybQ@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox