Re: [Mesa-dev] Direct3D 9 state tracker
Hello, one day I bought Mass Effect 3, but currently I'm not really able to play it on my Linux laptop featuring 3.0 Mesa 9.1.4. Gallium 0.4 on AMD CEDAR I tried the fglrx driver, but it gives more problems than it solves (yet the fps is there). With the radeon driver I manage to get to an ALMOST decent frame rate, meaning that is barely playable. In conclusion I would like to try this new D3D9, but would somebody be so kind to drop me 10 lines as a guideline to do it? Thanks in advance, Carlo. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Direct3D 9 state tracker [amended]
Hello, one day I bought Mass Effect 3, but currently I'm not really able to play it on my Linux laptop featuring 3.0 Mesa 9.1.4. Gallium 0.4 on AMD CEDAR I tried the fglrx driver, but it gives more problems than it solves (yet the fps is there). With the radeon driver I manage to get to an ALMOST decent frame rate, meaning that is barely playable. In conclusion I would like to try this new D3D9, but would somebody be so kind to drop me 10 lines as a guideline to do it? Plese consider that Mass Effect 3 appear to run only on wine 5.8 i386 (my laptop is 64 bit), so I should patch that very version. Thanks in advance, Carlo 2013/8/15 Carlo Marchiori carlo.marchi...@gmail.com Hello, one day I bought Mass Effect 3, but currently I'm not really able to play it on my Linux laptop featuring 3.0 Mesa 9.1.4. Gallium 0.4 on AMD CEDAR I tried the fglrx driver, but it gives more problems than it solves (yet the fps is there). With the radeon driver I manage to get to an ALMOST decent frame rate, meaning that is barely playable. In conclusion I would like to try this new D3D9, but would somebody be so kind to drop me 10 lines as a guideline to do it? Thanks in advance, Carlo. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Direct3D 9 state tracker
Hi Chris
Just a quick note for any Gentoo users - I've added these alternative
sources into the FireBurn overlay
You just need to set the nine use flag and you'll get Chris's versions
Cheers
Mike
On 16 July 2013 19:43, Christoph Bumiller e0425...@student.tuwien.ac.atwrote:
So, about two months ago I had the insane idea to pick up Joakim
Sindholt's Direct3D 9 state tracker that he'd started about 3 years ago
with the goal to make it run StarCraft 2 so I could finally play at a
reasonable frame rate ...
With help from Joakim and advice from the wine developers, as well as
wine's d3d9 tests, things went surprisingly smooth and my original goal
has been achieved and surpassed, hence I thought I'd post a note here in
case someone who doesn't yet know about it is interested in trying it out.
... Now wait, didn't we have a D3D10/11 state tracker already that we
kicked out because it was unmaintained and not really useful ?
Yes, but there are a couple of differences to d3d1x:
- the original author has not vanished [yet] (Luca, if you can hear me:
You cannot leave your children out to die like that !)
- it's written in C instead of C++ and not relying on horrific multiple
inheritance with templates hacks to make gcc generate COM-compatible
vtables (and I'm still not sure if that actually worked)
- gallium wasn't ready for D3D11, and still isn't (at least the pipe
drivers aren't), but it is ready for D3D9, and all the features required
from the pipe drivers are well tested via OpenGL
- there are no motivating applications using Direct3D 10/11 yet (at
least for me)
- and most importantly, contrary to d3d1x, d3d9/st already actually
works for real applications !
So far I've tried Skyrim, Civilization 5, Anno 1404 and StarCraft 2 on
the nvc0 and r600g drivers, which work pretty well, at up to x2 the fps
I get with wined3d (NOTE: no thorough benchmarking done yet).
Civilization 4 works, too, but it still has a couple of (not too severe)
rendering issues because I didn't pay much attention to the fixed
function pipeline and its interaction with the earlier shader versions yet.
If people think it's a good idea to merge it, I'd clean up the few
modifications I did to gallium, and, once they've been cleared, merge
the state tracker itself.
Unfortunately, for proper window system integration, a few modifications
to wine are required (it used to run without them, but fully correct
operation isn't possible like that).
Here's the links to the mesa branch containing the state tracker and to
a patched version of wine:
https://github.com/chrisbmr/Mesa-3D/tree/gallium-nine
https://github.com/chrisbmr/wine/tree/d3dadapter9-wip
(The wine modifications only affect { d3d9.dll.so, gdi32.dll.so,
user32.dll.so, wineps.drv.so and winex11.drv.so }, so you don't have to
replace all of it).
Some usage hints:
https://github.com/chrisbmr/Mesa-3D/blob/gallium-nine/src/gallium/state_trackers/nine/README
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Direct3D 9 state tracker
- Original Message - So, about two months ago I had the insane idea to pick up Joakim Sindholt's Direct3D 9 state tracker that he'd started about 3 years ago with the goal to make it run StarCraft 2 so I could finally play at a reasonable frame rate ... With help from Joakim and advice from the wine developers, as well as wine's d3d9 tests, things went surprisingly smooth and my original goal has been achieved and surpassed, hence I thought I'd post a note here in case someone who doesn't yet know about it is interested in trying it out. ... Now wait, didn't we have a D3D10/11 state tracker already that we kicked out because it was unmaintained and not really useful ? Yes, but there are a couple of differences to d3d1x: - the original author has not vanished [yet] (Luca, if you can hear me: You cannot leave your children out to die like that !) - it's written in C instead of C++ and not relying on horrific multiple inheritance with templates hacks to make gcc generate COM-compatible vtables (and I'm still not sure if that actually worked) - gallium wasn't ready for D3D11, and still isn't (at least the pipe drivers aren't), but it is ready for D3D9, and all the features required from the pipe drivers are well tested via OpenGL - there are no motivating applications using Direct3D 10/11 yet (at least for me) - and most importantly, contrary to d3d1x, d3d9/st already actually works for real applications ! So far I've tried Skyrim, Civilization 5, Anno 1404 and StarCraft 2 on the nvc0 and r600g drivers, which work pretty well, at up to x2 the fps I get with wined3d (NOTE: no thorough benchmarking done yet). Civilization 4 works, too, but it still has a couple of (not too severe) rendering issues because I didn't pay much attention to the fixed function pipeline and its interaction with the earlier shader versions yet. If people think it's a good idea to merge it, I'd clean up the few modifications I did to gallium, and, once they've been cleared, merge the state tracker itself. Unfortunately, for proper window system integration, a few modifications to wine are required (it used to run without them, but fully correct operation isn't possible like that). My stance is the same I had with D3D10 state-tracker: - I haven't looked at the code yet, but in principle I don't oppose merging as long as it is maintained in a building and running state, in particular in face of interface changes [1]. That said, given the past track record, I suspect it won't survive if it remains an one-man-project. That is, more than to merge or not merge issue, I'd focus on making this appealing to a wider audience. - It seems to me that this would be more useful if the state tracker targeted not the D3D9 API, but the WDDM D3D9 DDI [2]. Targeting the DDI would allow, e.g., to share more code with rest of WINE (the API-DDI runtime layer); to conveniently switch between this Gallium implementation and the current D3D9 GL implementation; ReactOS could also use the runtime bits for native IHV driver support; people wanting to write native gallium Windows drivers could also use the state tracker as a starting point, and one might even be able to run this with Microsoft conformance tests on Windows to test/validate it. But as it stands now -- a D3D9 runtime drop-in replacement --, I really see no use outside WINE (and maybe not even that, if D3D11.x's history repeats.) These are just my 2c. I really have no vested interest in this: either way, I'm afraid that it is very unlikely that this ever becomes of direct use to me or my employer. But I'd still prefer to see this succeed in some form, as I believe that Gallium ecosystem would be healthier with more state trackers out there supporting different APIs. Jose [1] For example, as we cleanup TGSI opcodes, I think we should refactor TGSI opcodes such that instead of being a messy superset GL ARB opcodes + D3D9 opcodes + D3D1x opcodes they become a leaner abstraction of these APIs, because there are way more pipe drivers than state trackers (and that's an unavoidable trend, as APIs tend to stick a round much longer than particular pieces of HW), so we should weigh on making pipe driver implementers' lives easier. [2] http://msdn.microsoft.com/en-us/library/windows/hardware/ff552927.aspx ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Direct3D 9 state tracker
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-07-22 15:39, schrieb Jose Fonseca: It seems to me that this would be more useful if the state tracker targeted not the D3D9 API, but the WDDM D3D9 DDI [2]. Targeting the DDI would allow, e.g., to share more code with rest of WINE (the API-DDI runtime layer); Fwiw, Wine does not use Microsoft's DDI in any way. We use our own interface to abstract between d3d versions, which is a mix of d3d9 and d3d10, with some ddraw-specific extras. Our main d3d module (wined3d.dll) has some internal abstraction layers for shader translation and fixed function pipeline implementations. Right now we have implementations based on GLSL, ARB_program, ATI_fragment_shader, NV_texture_shader and ARB_texture_env_combine, as well as code to handle OpenGL fixed function vertex processing. Adding a gallium-based backend should be a relatively easy challenge. The bigger problem would be resource creation and loading (buffers, textures) because there's no abstraction for that yet. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR7WJyAAoJEN0/YqbEcdMwjVcP/ihUVZd66dRr2X8f49j23muX biuF1KbcFsB1+LeTtH50iuDn8gdnPiTJWdrwju3wfs4IRsmA8IfQSxeBElIuEyEZ o+2keEmsR9/aDZvI4uilfzVmtcaNzCZWnzKkVOctDHaxVaW52fH2OaB01weQXL/r gT5dMFhkVc8vN6BFiawrnvZDArewIFa8XDBhdyz7tWpamel8UF922otBzrVDoK0o pFQqcZLrdvtCSVq5uHVzKqc/jRP2FuNCVlvKrrwTrjWIO/q3F5oB0SJDUXd8xp1K zJRSVB1U4MzVRE5jf5X+s+nMrsLEME0DBQCNYtsh3veLFDS98UCkoWDAGC7IPgrX 0zfeXITeq6dm0CvN7cGUFCmm+GO+vlwRTsFiAmAp5tvhOBIcyUTPO36LBcxMxtQQ p+KubboWMCDTPWnidPh3LpbXE+y2JVfsfpviVykRdNAgxiI28lcVuHMSkyLahQ9s fbLGc4fR+WbGwBVAkWE9HZ3y9kr3O+aUK+m70d7mwYEwV0ZhJEGRZibLnK2JHHNf B0NJJ9YmU64LmDOfUGzHU4rhbQfURk6SSh+ys3+iNPUSL2iCNGRf4QS01qAeoW0/ RITNPENBWlzQJWgkED2yLp28q/ZB3YCGn92/TpU7IHucd1eZzF+IPY5M+MKRPWXm JZ1TJlKvmP12YUAXgBNV =JxrZ -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Direct3D 9 state tracker
On 22 July 2013 18:48, Stefan Dösinger stefandoesin...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-07-22 15:39, schrieb Jose Fonseca: It seems to me that this would be more useful if the state tracker targeted not the D3D9 API, but the WDDM D3D9 DDI [2]. Targeting the DDI would allow, e.g., to share more code with rest of WINE (the API-DDI runtime layer); Fwiw, Wine does not use Microsoft's DDI in any way. We use our own interface to abstract between d3d versions, which is a mix of d3d9 and d3d10, with some ddraw-specific extras. Yes, although the DDI would probably be something we could work with on the wined3d level. The current interface would indeed be a bit awkward for us, at least from the point of view of integrating it into Wine itself. If we were to use an API that's not OpenGL in Wine, and we got to choose, we'd probably prefer using Gallium, or something similar to it, directly from wined3d. Any credible long term solution would either need to work with everything from ddraw to d3d11, or at least be capable of being made to work for those. Note also that there are applications that mix e.g. ddraw and d3d9, or ddraw and OpenGL. Those all need to work as well. That's not to say I don't think this is a useful project, at the very least it helps people with Gallium drivers and the applications that work with this state tracker. It also probably gives a good indication of what's possible in terms of performance. However, at this point I don't see how it can turn into a broader, more long term solution for Wine. From our point of view though, and I'm pretty sure I've mentioned this before to Christoph, the more interesting question is where most of the performance difference comes from. I.e., if that's mostly something specific to Mesa's GL implementation, something in how we're using GL, something inherent in the GL API, or something else entirely. I'm sure the additional abstraction layer doesn't help performance much, but I'm not all that convinced that that's enough to explain the difference. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Direct3D 9 state tracker
I think this is radically different from d3d1x, as it already can be used to play games from Blizzard, Bethesda, and other companies according to Christoph. I don't think this is much about what's best for Wine, because Wine has to work on multiple operating systems/drivers anyway. I think this is about what's best for the open source graphics drivers, and skipping the OpenGL middle layer is certainly not a bad idea. I think Wine should allow drivers, both open and closed, to implement d3d9 by themselves. In any case, wined3d can be used as a fallback if no compatible d3d9 driver has been found, which has already been implemented by Christoph if I understood him correctly. I see no problem with this. Let's merge the Wine patches, then the d3d9 state tracker, then let the community test it and report bugs. Once we're comfortable with it, we can enable building the d3d9 gallium drivers by default and the user base should skyrocket. Isn't it a good plan? Marek On Mon, Jul 22, 2013 at 3:39 PM, Jose Fonseca jfons...@vmware.com wrote: - Original Message - So, about two months ago I had the insane idea to pick up Joakim Sindholt's Direct3D 9 state tracker that he'd started about 3 years ago with the goal to make it run StarCraft 2 so I could finally play at a reasonable frame rate ... With help from Joakim and advice from the wine developers, as well as wine's d3d9 tests, things went surprisingly smooth and my original goal has been achieved and surpassed, hence I thought I'd post a note here in case someone who doesn't yet know about it is interested in trying it out. ... Now wait, didn't we have a D3D10/11 state tracker already that we kicked out because it was unmaintained and not really useful ? Yes, but there are a couple of differences to d3d1x: - the original author has not vanished [yet] (Luca, if you can hear me: You cannot leave your children out to die like that !) - it's written in C instead of C++ and not relying on horrific multiple inheritance with templates hacks to make gcc generate COM-compatible vtables (and I'm still not sure if that actually worked) - gallium wasn't ready for D3D11, and still isn't (at least the pipe drivers aren't), but it is ready for D3D9, and all the features required from the pipe drivers are well tested via OpenGL - there are no motivating applications using Direct3D 10/11 yet (at least for me) - and most importantly, contrary to d3d1x, d3d9/st already actually works for real applications ! So far I've tried Skyrim, Civilization 5, Anno 1404 and StarCraft 2 on the nvc0 and r600g drivers, which work pretty well, at up to x2 the fps I get with wined3d (NOTE: no thorough benchmarking done yet). Civilization 4 works, too, but it still has a couple of (not too severe) rendering issues because I didn't pay much attention to the fixed function pipeline and its interaction with the earlier shader versions yet. If people think it's a good idea to merge it, I'd clean up the few modifications I did to gallium, and, once they've been cleared, merge the state tracker itself. Unfortunately, for proper window system integration, a few modifications to wine are required (it used to run without them, but fully correct operation isn't possible like that). My stance is the same I had with D3D10 state-tracker: - I haven't looked at the code yet, but in principle I don't oppose merging as long as it is maintained in a building and running state, in particular in face of interface changes [1]. That said, given the past track record, I suspect it won't survive if it remains an one-man-project. That is, more than to merge or not merge issue, I'd focus on making this appealing to a wider audience. - It seems to me that this would be more useful if the state tracker targeted not the D3D9 API, but the WDDM D3D9 DDI [2]. Targeting the DDI would allow, e.g., to share more code with rest of WINE (the API-DDI runtime layer); to conveniently switch between this Gallium implementation and the current D3D9 GL implementation; ReactOS could also use the runtime bits for native IHV driver support; people wanting to write native gallium Windows drivers could also use the state tracker as a starting point, and one might even be able to run this with Microsoft conformance tests on Windows to test/validate it. But as it stands now -- a D3D9 runtime drop-in replacement --, I really see no use outside WINE (and maybe not even that, if D3D11.x's history repeats.) These are just my 2c. I really have no vested interest in this: either way, I'm afraid that it is very unlikely that this ever becomes of direct use to me or my employer. But I'd still prefer to see this succeed in some form, as I believe that Gallium ecosystem would be healthier with more state trackers out there supporting different APIs. Jose [1] For example, as we cleanup TGSI opcodes, I think we should refactor TGSI opcodes such that
Re: [Mesa-dev] Direct3D 9 state tracker
On Tue, Jul 23, 2013 at 8:21 AM, Marek Olšák mar...@gmail.com wrote: I think this is radically different from d3d1x, as it already can be used to play games from Blizzard, Bethesda, and other companies according to Christoph. I don't think this is much about what's best for Wine, because Wine has to work on multiple operating systems/drivers anyway. I think this is about what's best for the open source graphics drivers, and skipping the OpenGL middle layer is certainly not a bad idea. I think Wine should allow drivers, both open and closed, to implement d3d9 by themselves. In any case, wined3d can be used as a fallback if no compatible d3d9 driver has been found, which has already been implemented by Christoph if I understood him correctly. I see no problem with this. Let's merge the Wine patches, then the d3d9 state tracker, then let the community test it and report bugs. Once we're comfortable with it, we can enable building the d3d9 gallium drivers by default and the user base should skyrocket. Isn't it a good plan? Totally, if we can find some way for wine to pick up the dll so distros can package it even better. Like some sort of search path for /usr/lib64/dri/ or a look for winemesad3d.dll first then fallback to the wined3d.dll (or however this works). Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Direct3D 9 state tracker
So, about two months ago I had the insane idea to pick up Joakim
Sindholt's Direct3D 9 state tracker that he'd started about 3 years ago
with the goal to make it run StarCraft 2 so I could finally play at a
reasonable frame rate ...
With help from Joakim and advice from the wine developers, as well as
wine's d3d9 tests, things went surprisingly smooth and my original goal
has been achieved and surpassed, hence I thought I'd post a note here in
case someone who doesn't yet know about it is interested in trying it out.
... Now wait, didn't we have a D3D10/11 state tracker already that we
kicked out because it was unmaintained and not really useful ?
Yes, but there are a couple of differences to d3d1x:
- the original author has not vanished [yet] (Luca, if you can hear me:
You cannot leave your children out to die like that !)
- it's written in C instead of C++ and not relying on horrific multiple
inheritance with templates hacks to make gcc generate COM-compatible
vtables (and I'm still not sure if that actually worked)
- gallium wasn't ready for D3D11, and still isn't (at least the pipe
drivers aren't), but it is ready for D3D9, and all the features required
from the pipe drivers are well tested via OpenGL
- there are no motivating applications using Direct3D 10/11 yet (at
least for me)
- and most importantly, contrary to d3d1x, d3d9/st already actually
works for real applications !
So far I've tried Skyrim, Civilization 5, Anno 1404 and StarCraft 2 on
the nvc0 and r600g drivers, which work pretty well, at up to x2 the fps
I get with wined3d (NOTE: no thorough benchmarking done yet).
Civilization 4 works, too, but it still has a couple of (not too severe)
rendering issues because I didn't pay much attention to the fixed
function pipeline and its interaction with the earlier shader versions yet.
If people think it's a good idea to merge it, I'd clean up the few
modifications I did to gallium, and, once they've been cleared, merge
the state tracker itself.
Unfortunately, for proper window system integration, a few modifications
to wine are required (it used to run without them, but fully correct
operation isn't possible like that).
Here's the links to the mesa branch containing the state tracker and to
a patched version of wine:
https://github.com/chrisbmr/Mesa-3D/tree/gallium-nine
https://github.com/chrisbmr/wine/tree/d3dadapter9-wip
(The wine modifications only affect { d3d9.dll.so, gdi32.dll.so,
user32.dll.so, wineps.drv.so and winex11.drv.so }, so you don't have to
replace all of it).
Some usage hints:
https://github.com/chrisbmr/Mesa-3D/blob/gallium-nine/src/gallium/state_trackers/nine/README
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Direct3D 9 state tracker
Em 16-07-2013 16:43, Christoph Bumiller escreveu: So far I've tried Skyrim, Civilization 5, Anno 1404 and StarCraft 2 on the nvc0 and r600g drivers, which work pretty well, at up to x2 the fps I get with wined3d (NOTE: no thorough benchmarking done yet). Oblivion sucks fps wise nowdays, I wonder how fast it will go with this. Don't forget to also ping the wine list with your changes. Solerman ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
