[Mesa-dev] [PATCH] drm/radeon: Fix vram_size/visible values in DRM_RADEON_GEM_INFO ioctl

[Alex Deucher]

On Tue, Jan 31, 2017 at 5:06 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 31 January 2017 at 15:43, Deucher, Alexander
> <Alexander.Deucher at amd.com> wrote:
>>> -----Original Message-----
>>> From: amd-gfx [mailto:amd-gfx-bounces at 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 at lists.freedesktop.org; amd-
>>> gfx at 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.
>>
> vram_size is used for available_texture_mem in st/nine and
> GLX_RENDERER_VIDEO_MEMORY_MESA via GLX_MESA_query_renderer.
> So maybe we want this in older/stable kernel and mesa releases ? Not
> sure how many apps use/honour these though ;-)

vram_size was always correct.  it was just visible vram size that was wrong.

Alex