secondlife / jira-archive

2 stars 0 forks source link

[BUG-5482] llwindowsdl.cpp x11_detect_VRAM_kb_fp hacks failing for modern radeon #13458

Open sl-service-account opened 10 years ago

sl-service-account commented 10 years ago

Steps to Reproduce

This is consistent for every login The pairs of error messages appear - first 128, then 512 They also appear when the window resets during a graphic setting change.

Actual Behavior

2014-03-22T17:13:13Z WARNING: newview/llviewertexturelist.cpp(1403) : LLViewerTextureList::getMaxVideoRamSetting: VRAM amount not detected, defaulting to 128 MB 2014-03-22T17:13:13Z WARNING: newview/llviewertexturelist.cpp(1403) : LLViewerTextureList::getMaxVideoRamSetting: VRAM amount not detected, defaulting to 512 MB

Expected Behavior

Viewer detects 1024M and defaults to viewer max of 512M rather than 128M.

Other information

There are several related here - the viewer limits to 128M even though the error says both 128 or 512. The frustrating part is that with it capping at 128M - a lot of texture cache thrashing happens in many places you visit.

The root cause seems to be the hackery-foo in: llwindow/llwindowsdl.cpp

if LL_X11

function: x11_detect_VRAM_kb_fp

Recent Xorg are not showing the VideoRAM/Video RAM/Memory message as expected in Xorg.0.log Instead, for the native radeon driver with my card, the messages in Xorg.0.log are: [ 81.005] (II) RADEON(0): EXA: Driver will allow EXA pixmaps in VRAM [ 81.007] (II) RADEON(0): VRAM usage limit set to 912261K

Another log-scraping detection message seems to be in /var/log/messages: Mar 22 11:06:35 thuban kernel: [ 1.874307] radeon 0000:03:00.0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used) Mar 22 11:06:35 thuban kernel: [ 1.874530] [drm] radeon: 1024M of VRAM memory ready Mar 22 11:06:35 thuban kernel: [ 2.623893] radeon 0000:04:00.0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used) Mar 22 11:06:35 thuban kernel: [ 2.623905] [drm] radeon: 1024M of VRAM memory ready

Note: the 5970 is a DUAL GPU card, and is showing card0 (in PCI 03:00.0) AND card1 (in PCI 04:00.0) here

Also, there is a LOT of card state information stored in /sys or /proc on Linux which may help. The AMD or Mesa folks may have an API/programmatic way to do this which is better than log scraping.

Anyway the viewer is usable but this part could be a lot better and seems to be an old hack which needs updating for more recent Xorg and radeon drivers.

Original Jira Fields | Field | Value | | ------------- | ------------- | | Issue | BUG-5482 | | Summary | llwindowsdl.cpp x11_detect_VRAM_kb_fp hacks failing for modern radeon | | Type | Bug | | Priority | Unset | | Status | Accepted | | Resolution | Accepted | | Reporter | Allen Kerensky (allen.kerensky) | | Created at | 2014-03-22T18:02:00Z | | Updated at | 2014-03-26T16:56:00Z | ``` { 'Business Unit': ['Platform'], 'Date of First Response': '2014-03-22T13:16:31.142-0500', "Is there anything you'd like to add?": 'There are several related here - the viewer limits to 128M even though the error says both 128 or 512.\r\nThe frustrating part is that with it capping at 128M - a lot of texture cache thrashing happens in many places you visit.\r\n\r\nThe root cause seems to be the hackery-foo in:\r\nllwindow/llwindowsdl.cpp\r\n#if LL_X11\r\nfunction: x11_detect_VRAM_kb_fp\r\n\r\nRecent Xorg are not showing the VideoRAM/Video RAM/Memory message as expected in Xorg.0.log\r\nInstead, for the native radeon driver with my card, the messages in Xorg.0.log are:\r\n[ 81.005] (II) RADEON(0): EXA: Driver will allow EXA pixmaps in VRAM\r\n[ 81.007] (II) RADEON(0): VRAM usage limit set to 912261K\r\n\r\nAnother log-scraping detection message seems to be in /var/log/messages:\r\nMar 22 11:06:35 thuban kernel: [ 1.874307] radeon 0000:03:00.0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used)\r\nMar 22 11:06:35 thuban kernel: [ 1.874530] [drm] radeon: 1024M of VRAM memory ready\r\nMar 22 11:06:35 thuban kernel: [ 2.623893] radeon 0000:04:00.0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used)\r\nMar 22 11:06:35 thuban kernel: [ 2.623905] [drm] radeon: 1024M of VRAM memory ready\r\n\r\nNote: the 5970 is a DUAL GPU card, and is showing card0 (in PCI 03:00.0) AND card1 (in PCI 04:00.0) here\r\n\r\nAlso, there is a LOT of card state information stored in /sys or /proc on Linux which may help.\r\nThe AMD or Mesa folks may have an API/programmatic way to do this which is better than log scraping.\r\n\r\nAnyway the viewer is usable but this part could be a lot better and seems to be an old hack which needs updating for more recent Xorg and radeon drivers.\r\n', 'System': 'SL Viewer', 'Target Viewer Version': 'viewer-development', 'What just happened?': '2014-03-22T17:13:13Z WARNING: newview/llviewertexturelist.cpp(1403) : LLViewerTextureList::getMaxVideoRamSetting: VRAM amount not detected, defaulting to 128 MB\r\n2014-03-22T17:13:13Z WARNING: newview/llviewertexturelist.cpp(1403) : LLViewerTextureList::getMaxVideoRamSetting: VRAM amount not detected, defaulting to 512 MB\r\n', 'What were you doing when it happened?': 'This is consistent for every login\r\nThe pairs of error messages appear - first 128, then 512\r\nThey also appear when the window resets during a graphic setting change.', 'What were you expecting to happen instead?': 'Viewer detects 1024M and defaults to viewer max of 512M rather than 128M.', } ```
sl-service-account commented 10 years ago

Whirly Fizzle commented at 2014-03-22T18:16:31Z

I dont know if this will help with your issue, but you may be interested in a change that's lurking in Tiger: https://bitbucket.org/lindenlab/viewer-tiger/commits/8425f76bbb1de290c9c4956a2e0579d4a05a0112

sl-service-account commented 10 years ago

Allen Kerensky commented at 2014-03-22T22:20:04Z

I am not sure if I am reading that correctly - is it saying there's a new Debug setting that can be set - or is it letting the slider get bigger only? Right now - its not detecting anything because its looking for old messages - so its clamping at 128 - even if the slider lets me set as high as 512. If I do bump it up - it simply resets itself back to 128 regardless. My note above is more about how to detect the card's VRAM setting itself using some of the other places and ways it shows up - rather than JUST the traditional Video*RAM/Memory log scraper. But the part of that change I could read - separating texture from total memory and allowing up to 4G max instead of 512M looks good anyway.