I am trying some simple patches for: http://bugs.winehq.org/show_bug.cgi?id=24642
and noticed that although glxinfo reports: misha@ubuntu:~/.wine/drive_c/Program Files/Tag$ glxinfo | grep -i render direct rendering: Yes OpenGL renderer string: Parallels using NVIDIA GeForce GT 330M OpenGL Engine
I get: misha@ubuntu:~/.wine/drive_c/Program Files/Tag$ wine Tag.exe err:winediag:X11DRV_WineGL_InitOpenglInfo The Mesa OpenGL driver is using software rendering, most likely your OpenGL drivers haven't been installed correctly fixme:d3d_caps:wined3d_guess_card No card selector available for GL vendor 4 and card vendor 0000. fixme:win:EnumDisplayDevicesW ((null),0,0x32e6f4,0x00000000), stub!
and I get different results under Parallels than running directly on the Mac
This does not seem to cause a problem for other game demos, such as http://bugs.winehq.org/show_bug.cgi?id=24642, but the message is still there.
Any ideas?
Thank you Misha
p.s. I compiled wine git with: ./configure CPPFLAGS='-I/usr/X11/include' LIBS='-lGL -lGLU' LDFLAGS='-L/usr/X11/lib' make && sudo make install
and am using the command: DYLD_FALLBACK_LIBRARY_PATH="/usr/X11/lib:/usr/lib" wine ...
on the Mac side.
Thank you.
On 15 February 2011 21:37, Misha Koshelev misha680@gmail.com wrote:
and noticed that although glxinfo reports: misha@ubuntu:~/.wine/drive_c/Program Files/Tag$ glxinfo | grep -i render direct rendering: Yes OpenGL renderer string: Parallels using NVIDIA GeForce GT 330M OpenGL Engine
Is that a 32-bit or 64-bit Ubuntu? The 32-bit drivers on 64-bit Ubuntu have a tendency to be broken, although in this case that would probably be Parallels' responsibility and not Ubuntu's. Two general points though: - Don't use Ubuntu for serious development. - Don't use VMs for GL/D3D development, unless you can fix the drivers yourself.
I'm sure it's all kinds of fun to make it work, but it's not very productive, and you end up with a somewhat questionable configuration for testing.
On Tue, Feb 15, 2011 at 6:50 PM, Henri Verbeet hverbeet@gmail.com wrote:
On 15 February 2011 21:37, Misha Koshelev misha680@gmail.com wrote:
and noticed that although glxinfo reports: misha@ubuntu:~/.wine/drive_c/Program Files/Tag$ glxinfo | grep -i render direct rendering: Yes OpenGL renderer string: Parallels using NVIDIA GeForce GT 330M OpenGL Engine
Is that a 32-bit or 64-bit Ubuntu?
64-bit.
The 32-bit drivers on 64-bit Ubuntu have a tendency to be broken, although in this case that would probably be Parallels' responsibility and not Ubuntu's. Two general points though: - Don't use Ubuntu for serious development.
What would you recommend using? Do you mean MacOS itself in this specific instance, or was that a general comment (i.e., use Fedora not Ubuntu).
- Don't use VMs for GL/D3D development, unless you can fix the drivers yourself.
Thank you. Duly noted.
I'm sure it's all kinds of fun to make it work, but it's not very productive, and you end up with a somewhat questionable configuration for testing.
Misha
p.s. As a note I've actually had similar results in my testing with Mac OS vs VMs. In fact, there are some bugs I was _only_ able to reproduce in the VM (I got an error about a mode not being available within the Mac OS version).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 16.02.2011 um 02:24 schrieb Misha Koshelev:
What would you recommend using? Do you mean MacOS itself in this specific instance, or was that a general comment (i.e., use Fedora not Ubuntu).
I am nowadays mostly using Linux for development, but I also have my Wine development stuff also set up on OSX, and it is working okish. Some things are better(e.g. the GL profiler is cool, if it works), some things are troublesome(e.g. it is generally slower, some newer extensions are missing).
I'd prefer MacOS over Linux in a VM. Linux vs MacOS directly on the hardware is a matter of taste and where you feel at home. The advantage of Linux is that if you have a situation where something behaves oddly there are more people who know your platform. On the other hand, Wine could certainly use more Mac devs.
My Linux is installed on a USB disk with an EFI bootloader so I can comfortably boot it on OSX by holding down the Alt key. However, the reason for that are other machines, not the macbook.(switch work environment quickly without maintaining 5 installations),
Stefan
PS: I don't intend to interpret Henri's words, this mail is meant as a general MacOS+Wine development experience report.
On Wed, Feb 16, 2011 at 4:00 PM, Stefan Dösinger stefandoesinger@gmx.at wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 16.02.2011 um 02:24 schrieb Misha Koshelev:
What would you recommend using? Do you mean MacOS itself in this specific instance, or was that a general comment (i.e., use Fedora not Ubuntu).
I am nowadays mostly using Linux for development, but I also have my Wine development stuff also set up on OSX, and it is working okish. Some things are better(e.g. the GL profiler is cool, if it works), some things are troublesome(e.g. it is generally slower, some newer extensions are missing).
I'd prefer MacOS over Linux in a VM. Linux vs MacOS directly on the hardware is a matter of taste and where you feel at home. The advantage of Linux is that if you have a situation where something behaves oddly there are more people who know your platform. On the other hand, Wine could certainly use more Mac devs.
My Linux is installed on a USB disk with an EFI bootloader so I can comfortably boot it on OSX by holding down the Alt key. However, the reason for that are other machines, not the macbook.(switch work environment quickly without maintaining 5 installations),
Stefan
PS: I don't intend to interpret Henri's words, this mail is meant as a general MacOS+Wine development experience report.
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
iQIcBAEBAgAGBQJNXDsKAAoJEN0/YqbEcdMwoVcQAIKbvZBiBeRdcMnh2mfmqaMo cJQcwn3aC8QKD5Bc+nZ+fubQhMZfx2nyPuCTxWQ5jVP4IPjL0oDkbbpbPLQIqoXj IGDabouv7cEbvT0IZkS5FE2rpHe2vgrVUjEPnWGXLTPt0O//uDn+AVozaWwEdw8l 9OeuXQPv0pVA6F1jj4dAI5dODNcr9ShOhV1zrZfR7Y7rtWBxomnUgg0ExLjbkr7c x7ooq62GxeDcDw5qZY5gUVz/1N8nBRQUpUXUClTfdBfo1011kiFgUn9Copgr5lcT S3qazUBTbs2T4PsmQW8yJMxmaBn4m8OfiOkSHNnfZXPZ6T8ZifJBg0XhK3eNZ0Gm SWCYLs0eL35mOed4++VLEvCiOz69ZPi9WLhdv2ocO4OWehYhqQu3YKMXb98oHsJD vZFS6tMEpPEgWV+69lFzHe3oBUKLa48oljfEfLqrPAtU4Ak0eGT3QVSaTK0bw8dV AMgXMCQl3+hYheVxMYhYzASFs7FKo69F2CuQdMxo+1Ek5VsOYURoe14YdT8nTbgi j/AAMZhCSNuk67NVAH7xBhK8XXog0UD+MZeumH0IJyeLW64PfH+S06DG031GqvLO DTEd2u4FWbeNhfK1C85um5c9lzXcUIIP5tGwhhKeHwnURkE7nWgFZ0tsYt4oErwM bbs1jDqkJn6GVDR/eURS =zjQd -----END PGP SIGNATURE-----
Stefan,
Thanks a lot for your info!
Just out of curiosity - how did you build wine git on Mac OS X?
There is the simple way that I gleaned from several sources, namely:
./configure CPPFLAGS='-I/usr/X11/include' LIBS='-lGL -lGLU' LDFLAGS='-L/usr/X11/lib' make && sudo make install
and then, to use: DYLD_FALLBACK_LIBRARY_PATH="/usr/X11/lib:/usr/lib" wine ...
However, this seems to be missing quite a few libraries (libjpeg).
I tried to look at the MacPorts build commands by doing:
sudo port -d install wine-devel
and then copying the ./configure command:
./configure --prefix=/opt/local --without-alsa --without-audioio --without-capi --with-cms --with-coreaudio --with-cups --with-curses --without-esd --with-fontconfig --with-freetype --without-gphoto --with-glu --with-gnutls --without-gsm --without-hal --without-jack --with-jpeg --without-ldap --without-mpg123 --without-nas --without-openal --with-opengl --with-openssl --without-oss --with-png --with-pthread --without-sane --with-tiff --without-v4l --with-xcomposite --with-xcursor --with-xinerama --with-xinput --with-xml --with-xrandr --with-xrender --with-xshape --with-xshm --with-xslt --with-xxf86vm --with-x --x-include=/opt/local/include --x-lib=/opt/local/lib --verbose
but the build is failing to find the MacPorts libraries.
Any suggestions much appreciated.
Thank you Misha
For future reference, here is how I was able to quickly compile wine's git version with all the libraries helpfully installed by MacPorts.
sudo port install wine-devel
When this is finished, go to the Wine GIT folder, and do:
./configure CPPFLAGS='-I/usr/X11/include -I/opt/local/include' LIBS='-lGL -lGLU' LDFLAGS='-L/usr/X11/lib -L/opt/local/lib' make && sudo make install
Finally, edit your ~/.profile, and add the following line:
export DYLD_FALLBACK_LIBRARY_PATH="/usr/X11/lib:/usr/lib:/opt/local/lib"
Thank you. Hope this helps someone else.
Misha
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Actually, before reinstalling OSX I used the CrossOver X11 setup to compile and run Wine. It also has a few other missing libraries. On my other machine I compiled a few libraries from source by hand and for others I just ignored them.
Am 17.02.2011 um 17:17 schrieb Misha Koshelev:
For future reference, here is how I was able to quickly compile wine's git version with all the libraries helpfully installed by MacPorts.
sudo port install wine-devel
When this is finished, go to the Wine GIT folder, and do:
./configure CPPFLAGS='-I/usr/X11/include -I/opt/local/include' LIBS='-lGL -lGLU' LDFLAGS='-L/usr/X11/lib -L/opt/local/lib' make && sudo make install
Finally, edit your ~/.profile, and add the following line:
export DYLD_FALLBACK_LIBRARY_PATH="/usr/X11/lib:/usr/lib:/opt/local/lib"
Thank you. Hope this helps someone else.
Misha
On Thu, Feb 17, 2011 at 5:36 PM, Stefan Dösinger stefandoesinger@gmx.at wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Actually, before reinstalling OSX I used the CrossOver X11 setup to compile and run Wine. It also has a few other missing libraries. On my other machine I compiled a few libraries from source by hand and for others I just ignored them.
My apologies, but I am somewhat unfamiliar with the "CrossOver X11 setup." Would you mind elaborating?
Is this something proprietary to Codeweavers developers only?
Thank you Misha
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 18.02.2011 um 02:13 schrieb Misha Koshelev:
Is this something proprietary to Codeweavers developers only?
I am not sure. We release our Wine source code(required by the LGPL). We submitted the changes we made to our Xorg back to Apple and the Xorg developers, but I think we haven't released our source tree itself(not required by the X11 license), mostly because there's little reason to use it. I am using it because that way my development setup is closer to the actual product we ship, but it has no advantage over the Snow Leopard Apple X11 + a few hand compiled libraries. (Ok, I think our hacky xrandr implementation didn't make it into the upstream repo)