Bug 52997

what else do i need to submit and how to do it?

Please attach the /var/log/Xorg.0.log file.

Which version of libdrm_radeon are you using?

Created attachment 65141 [details]
varlog from startup untill crash of game

how to check the libdrm version?

Created attachment 66688 [details]
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

Created attachment 66689 [details]
X.org server varlog

Created attachment 67811 [details]
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:

Is this still an issue with a newer version of mesa?  git master or a 9.0 snapshot?

Created attachment 68018 [details]
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.

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.

(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.

(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.

(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).

(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.

(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.

(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.

-- 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.