https://bugs.freedesktop.org/show_bug.cgi?id=52997
Bug #: 52997 Summary: evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine Classification: Unclassified Product: Mesa Version: 8.0 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: stevenvandenbrandenstift@gmail.com
trying to run dungeon siege 2 via wine, intro plays fine and then hangs , found a radeon problem to be the cause.
dmegs output:
[ 7230.283645] radeon 0000:00:01.0: evergreen_cs_track_validate_cb:477 cb[0] bo too small (layer size -2147483648, offset 0, max layer 1, bo size 4096, slice 4194303) [ 7230.283665] radeon 0000:00:01.0: evergreen_cs_track_validate_cb:481 problematic surf: (32 8388608) (0 8 1 0 0 0 0) [ 7230.283675] radeon 0000:00:01.0: evergreen_packet3_check:2096 invalid cmd stream 783 [ 7230.283684] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! [ 7231.299423] radeon 0000:00:01.0: evergreen_cs_track_validate_cb:477 cb[0] bo too small (layer size -2147483648, offset 0, max layer 1, bo size 4096, slice 4194303) [ 7231.299434] radeon 0000:00:01.0: evergreen_cs_track_validate_cb:481 problematic surf: (32 8388608) (0 8 1 0 0 0 0) [ 7231.299439] radeon 0000:00:01.0: evergreen_packet3_check:2096 invalid cmd stream 783 [ 7231.299444] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
the wine errors (don't know if helpfull at all) show a directdraw problem
]$ wine ./.wine/drive_c/Program\ Files/2K\ Games/Dungeon\ Siege\ 2\ Broken\ World/DS2VideoConfig.exe fixme:ddraw:DirectDrawEnumerateExA flags 0x00000007 not handled radeon: The kernel rejected CS, see dmesg for more information. fixme:win:EnumDisplayDevicesW ((null),0,0x33e048,0x00000000), stub! radeon: The kernel rejected CS, see dmesg for more information. fixme:win:EnumDisplayDevicesW ((null),0,0x33e114,0x00000000), stub!
uname -a: 3.4.6-1-ARCH #1 SMP PREEMPT Fri Jul 20 08:21:26 CEST 2012 x86_64 GNU/Linux
glxinfo:
OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD PALM OpenGL version string: 2.1 Mesa 8.0.4 OpenGL shading language version string: 1.20
https://bugs.freedesktop.org/show_bug.cgi?id=52997
--- Comment #1 from stevenvandenbrandenstift@gmail.com 2012-07-31 18:38:32 UTC --- what else do i need to submit and how to do it?
https://bugs.freedesktop.org/show_bug.cgi?id=52997
--- Comment #2 from Michel Dänzer michel@daenzer.net 2012-08-03 07:49:18 UTC --- Please attach the /var/log/Xorg.0.log file.
Which version of libdrm_radeon are you using?
https://bugs.freedesktop.org/show_bug.cgi?id=52997
--- Comment #3 from stevenvandenbrandenstift@gmail.com 2012-08-05 11:33:51 UTC --- Created attachment 65141 --> https://bugs.freedesktop.org/attachment.cgi?id=65141 varlog from startup untill crash of game
https://bugs.freedesktop.org/show_bug.cgi?id=52997
--- Comment #4 from stevenvandenbrandenstift@gmail.com 2012-08-05 11:54:10 UTC --- how to check the libdrm version?
https://bugs.freedesktop.org/show_bug.cgi?id=52997
Michel Dänzer michel@daenzer.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #65141|text/x-log |text/plain mime type| | Attachment #65141|varlog.log |Xorg.0.log filename| |
https://bugs.freedesktop.org/show_bug.cgi?id=52997
--- Comment #5 from mailbox.tec@gmail.com 2012-09-05 17:22:26 UTC --- Created attachment 66688 --> https://bugs.freedesktop.org/attachment.cgi?id=66688 Messages from dmesg after running BGMain.exe in fullscreen.
Hello
I am experiencing the same issue with Wine 1.5.12 and Baldur's Gate.
The issue appears when BGMain.exe is launched fullscreen, without virtual desktop. In virtual desktop mode, it seems to be running fine. Also, if window switching is attempted (Ctrl+Tab) with game in fullscreen, tiny video output appears, occupying roughly 1/4th of screen resolution (which in full is 1280x1024) in top-left corner, the rest remaining black. It's very pixelated and shows game's main menu. With futher switching, it shows different desktop windows (if open), but latency is very low. Regardless of video output, sound is still played through alsa.
In my case, output from running the executable is:
radeon: The kernel rejected CS, see dmesg for more information. fixme:win:EnumDisplayDevicesW ((null),0,0x329c48,0x00000000), stub! fixme:d3d_surface:wined3d_surface_flip Ignoring flags 0x1.
uname: Linux 3.5.3-2-ck x86_64
glxinfo: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD BARTS OpenGL version string: 2.1 Mesa 8.0.4 OpenGL shading language version string: 1.20
libdrm_radeon version is 1.0.1
Possible duplicate: https://bugs.freedesktop.org/show_bug.cgi?id=47244
https://bugs.freedesktop.org/show_bug.cgi?id=52997
--- Comment #6 from mailbox.tec@gmail.com 2012-09-05 17:30:02 UTC --- Created attachment 66689 --> https://bugs.freedesktop.org/attachment.cgi?id=66689 X.org server varlog
https://bugs.freedesktop.org/show_bug.cgi?id=52997
--- Comment #7 from Fede fedevx@yahoo.com --- Created attachment 67811 --> https://bugs.freedesktop.org/attachment.cgi?id=67811&action=edit radeon errors in dmesg while playing DC Universe Online in wine
As I run the game, wine is complaining of:
radeon: The kernel rejected CS, see dmesg for more information
dmesg reports the errors shown in the attachment.
OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD CEDAR OpenGL version string: 2.1 Mesa 8.0.4 OpenGL shading language version string: 1.20 OpenGL extensions:
https://bugs.freedesktop.org/show_bug.cgi?id=52997
--- Comment #8 from Alex Deucher agd5f@yahoo.com --- Is this still an issue with a newer version of mesa? git master or a 9.0 snapshot?
https://bugs.freedesktop.org/show_bug.cgi?id=52997
--- Comment #9 from Fede fedevx@yahoo.com --- Created attachment 68018 --> https://bugs.freedesktop.org/attachment.cgi?id=68018&action=edit dmesg with Mesa 9.1
Same errors with Mesa 9.1.
Wine complains of: radeon: The kernel rejected CS, see dmesg for more information.
dmesg attached.
https://bugs.freedesktop.org/show_bug.cgi?id=52997
--- Comment #10 from Alex Deucher agd5f@yahoo.com --- Make sure you update your 32 bit 3D driver as you appear to be using a 64 bit distro and wine requires a 32 bit 3D driver.
https://bugs.freedesktop.org/show_bug.cgi?id=52997
--- Comment #11 from mailbox.tec@gmail.com --- (In reply to comment #10)
Make sure you update your 32 bit 3D driver as you appear to be using a 64 bit distro and wine requires a 32 bit 3D driver.
This issue appeared for me in 2D games/applications, too. Haven't yet tested with newer mesa.
https://bugs.freedesktop.org/show_bug.cgi?id=52997
--- Comment #12 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #11)
(In reply to comment #10)
Make sure you update your 32 bit 3D driver as you appear to be using a 64 bit distro and wine requires a 32 bit 3D driver.
This issue appeared for me in 2D games/applications, too. Haven't yet tested with newer mesa.
If they are 32-bit games, you'll hit the same issue.
https://bugs.freedesktop.org/show_bug.cgi?id=52997
--- Comment #13 from mailbox.tec@gmail.com --- (In reply to comment #12)
If they are 32-bit games, you'll hit the same issue.
Not meaning to question your expertise, but would you care to explain: if "wine requires 32-bit 3D driver" why virtual desktop (i.e. non-fullscreen) mode is running just fine? In my layman view this would mean wine's perfectly able to handle the 2D rendering and display on it's part without having to install 32-bit 3D driver (which in my case would require complete switch to closed source catalyst package and I'm a bit reluctant to do so).
https://bugs.freedesktop.org/show_bug.cgi?id=52997
--- Comment #14 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #13)
(In reply to comment #12)
If they are 32-bit games, you'll hit the same issue.
Not meaning to question your expertise, but would you care to explain: if "wine requires 32-bit 3D driver" why virtual desktop (i.e. non-fullscreen) mode is running just fine? In my layman view this would mean wine's perfectly able to handle the 2D rendering and display on it's part without having to install 32-bit 3D driver (which in my case would require complete switch to closed source catalyst package and I'm a bit reluctant to do so).
You can install a 32 bit version of the open source 3D driver as well. Just because the graphics in a game do not appear to be 3D, they generally still use a 3D API (OpenGL or Direct3D) which requires a 32 bit 3D driver since the apps are 32 bit. Also there seem to be several possibly unrelated issues now piled onto this bug.
https://bugs.freedesktop.org/show_bug.cgi?id=52997
--- Comment #15 from mailbox.tec@gmail.com --- (In reply to comment #14)
You can install a 32 bit version of the open source 3D driver as well. Just because the graphics in a game do not appear to be 3D, they generally still use a 3D API (OpenGL or Direct3D) which requires a 32 bit 3D driver since the apps are 32 bit. Also there seem to be several possibly unrelated issues now piled onto this bug.
You've focused on minor point about the inability of having open source 32-bit driver alongside 64-bit one. I don't know the cause of it, I only know that my distribution provides this kind of setup for closed source catalyst package: https://wiki.archlinux.org/index.php/Wine#Graphics_Drivers
To clarify, I do have 32-bit DRI Mesa drivers installed - the lib32-ati-dri package mentioned in the link above - but I assume you mean xorg kind of drivers. If this is some sort of distro-related bug, please state it so I can nag other people about it ;-)
At the same time, I see my main point about display being fine in virtual desktop mode has been ignored? To reiterate: it doesn't seem to me that, since Wine is capable of rendering and display on the very same setup in different mode, there are some unfullfilled requirements that block said display. After all, as I described before, even in fullscreen mode there was some kind of output, albeit buggy to the point of being unusable. But without the crucial part of plumbing there would be no output at all.
https://bugs.freedesktop.org/show_bug.cgi?id=52997
--- Comment #16 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #15)
You've focused on minor point about the inability of having open source 32-bit driver alongside 64-bit one. I don't know the cause of it, I only know that my distribution provides this kind of setup for closed source catalyst package: https://wiki.archlinux.org/index.php/Wine#Graphics_Drivers
I'm not following. You can have both 32-bit and 64-bit versions of the open source driver installed. If your distro doesn't allow it, it's broken. If other 32-bit and 64-bit libs also cannot both be installed, you may have bigger problems.
To clarify, I do have 32-bit DRI Mesa drivers installed - the lib32-ati-dri package mentioned in the link above - but I assume you mean xorg kind of drivers. If this is some sort of distro-related bug, please state it so I can nag other people about it ;-)
Is the 32-bit driver a recent version? Often distros only provide out of date 32-bit drivers on 64-bit distros.
At the same time, I see my main point about display being fine in virtual desktop mode has been ignored? To reiterate: it doesn't seem to me that, since Wine is capable of rendering and display on the very same setup in different mode, there are some unfullfilled requirements that block said display. After all, as I described before, even in fullscreen mode there was some kind of output, albeit buggy to the point of being unusable. But without the crucial part of plumbing there would be no output at all.
The symptoms you are experiencing are commonly seen with an out of date 32-bit 3D driver. If your 32-bit 3D driver is old, you may still be experiencing the problem. Also, there are several people on this bug report and the solution may still be relevant for them even if it doesn't help in your case.
https://bugs.freedesktop.org/show_bug.cgi?id=52997
GitLab Migration User gitlab-migration@fdo.invalid changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |MOVED
--- Comment #17 from GitLab Migration User gitlab-migration@fdo.invalid --- -- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/415.
dri-devel@lists.freedesktop.org