On Tue, Jan 31, 2017 at 5:06 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 31 January 2017 at 15:43, Deucher, Alexander > <alexander.deuc...@amd.com> wrote: >>> -----Original Message----- >>> From: amd-gfx [mailto:amd-gfx-boun...@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- >>> g...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
