Page 1 of 4 123 ... LastLast
Results 1 to 10 of 39

Thread: Direct3D 9 Support Stands A Chance Of Being Added To Mesa

  1. #1
    Join Date
    Jan 2007
    Posts
    14,605

    Default Direct3D 9 Support Stands A Chance Of Being Added To Mesa

    Phoronix: Direct3D 9 Support Stands A Chance Of Being Added To Mesa

    For several months now there's been a Direct3D 9 state tracker under development for Mesa that's making some headway and working out for bettering the Wine performance with D3D9 titles rather than using Wine's translation layer to OpenGL. While no official request for pulling the code has been issued, it looks like it might stand a chance of hitting mainline Mesa...

    http://www.phoronix.com/vr.php?view=MTc2NTg

  2. #2
    Join Date
    Nov 2009
    Location
    Italy
    Posts
    917

    Default

    Yes, please merge.
    I also have Gentoo ebuilds for wine-d3d9 if someone is interested. I will publish them soon on my website.
    ## VGA ##
    AMD: X1950XTX, HD3870, HD5870
    Intel: GMA45, HD3000 (Core i5 2500K)

  3. #3
    Join Date
    Jul 2014
    Posts
    2

    Default

    wine-1.7.24-d3dadapter.patch https://gist.github.com/Thermionix/329dddf2bf84d86e6383

    patch generation;
    Code:
    git clone https://github.com/iXit/wine.git
    cd wine
    git checkout d3dadapter9-wip
    git remote add upstream git://source.winehq.org/git/wine.git
    git fetch upstream
    git merge --no-edit upstream/master
    git diff upstream/master..d3dadapter9-wip > d3dadapter.patch
    Arch AUR PKGBUILDs;
    https://aur.archlinux.org/pkgbase/mesa-d3d9-git/
    https://aur.archlinux.org/packages/wine-d3dadapter-git/

  4. #4
    Join Date
    Dec 2010
    Location
    MA, USA
    Posts
    1,265

    Default

    I'm hesitant on the merge because I'm not sure if there are enough people actively maintaining it. It's one thing if it works, but if it breaks in the future, somebody has to fix it and if it isn't fixed it will have to be taken out.

  5. #5
    Join Date
    Apr 2010
    Posts
    20

    Default

    Quote Originally Posted by darkbasic View Post
    Yes, please merge.
    I also have Gentoo ebuilds for wine-d3d9 if someone is interested. I will publish them soon on my website.
    please do. fast
    do you have the ebuilds needed for mesa-d3d9 too?

  6. #6

    Default

    Mesa packages in my Ubuntu PPA include it .

    There is no wine package however, so you have to build it yourself or get it from other PPA.

  7. #7
    Join Date
    Oct 2012
    Location
    Sweden
    Posts
    297

    Default

    This coincide very neatly with the Radeon driver almost getting as fast as Catalyst.
    This is the power of open source, anything can happen if people are willing to work on it.

  8. #8
    Join Date
    Jul 2012
    Posts
    8

    Default

    I have read several articles on the state tracker recently and I'd like to check if I'm understanding it right.

    Someone has created a Direct3D implementation which runs upon Gallium. So Wine, rather than converting Windows Direct3D calls to Linux OpenGL ones, it instead converts them to the Linux Direct3D calls, saving a bit of overhead.

    But could these calls be made from Linux directly? Could we have native Direct3D games? Could someone porting a Direct3D game from Windows to Linux, rather than converting to OpenGL, just use this state tracker instead? (Obviously Gallium drivers only)

    Is there any extra overhead compared to OpenGL with Gallium?

    How complex is the Direct3D state tracker? With OpenGL there are functions like glVertex3f, glBindTexture. Are these the sort of functions which the state tracker exposes? Did they create an implementation of every DirectX function?

    When a graphics card supports "DirectX 10", what exactly does this mean? Are the DirectX functions somehow implemented in the card, so a state tracker somehow maps these functions to the card? What does it mean if a graphics card doesn't support DirectX 10 say?

    Sorry for loads of questions - I'm not entirely sure how graphics cards work.

  9. #9
    Join Date
    Nov 2009
    Location
    Italy
    Posts
    917

    Default

    Quote Originally Posted by arabek View Post
    please do. fast
    do you have the ebuilds needed for mesa-d3d9 too?
    I have all the needed ebuilds and they worked flawlessly last time I used them. I still didn't publish the ebuilds nor the benchmarks because d3d9 is mainly tested on nouveau and it didn't work very well on radeonsi.
    Anyway when it worked it was faster than wine-d3dstream (CSMT).
    ## VGA ##
    AMD: X1950XTX, HD3870, HD5870
    Intel: GMA45, HD3000 (Core i5 2500K)

  10. #10
    Join Date
    Oct 2013
    Posts
    363

    Default

    Quote Originally Posted by Anthony View Post
    I have read several articles on the state tracker recently and I'd like to check if I'm understanding it right.

    Someone has created a Direct3D implementation which runs upon Gallium. So Wine, rather than converting Windows Direct3D calls to Linux OpenGL ones, it instead converts them to the Linux Direct3D calls, saving a bit of overhead.

    But could these calls be made from Linux directly? Could we have native Direct3D games? Could someone porting a Direct3D game from Windows to Linux, rather than converting to OpenGL, just use this state tracker instead? (Obviously Gallium drivers only)

    Is there any extra overhead compared to OpenGL with Gallium?

    How complex is the Direct3D state tracker? With OpenGL there are functions like glVertex3f, glBindTexture. Are these the sort of functions which the state tracker exposes? Did they create an implementation of every DirectX function?

    When a graphics card supports "DirectX 10", what exactly does this mean? Are the DirectX functions somehow implemented in the card, so a state tracker somehow maps these functions to the card? What does it mean if a graphics card doesn't support DirectX 10 say?

    Sorry for loads of questions - I'm not entirely sure how graphics cards work.
    yes
    yes... and no. it would cause problems as there is only support for oss drivers, unless someone implemented this lib as dual in a sense of use this for oss and use wine gl implementation when non oss driver. that would also bring the world of hurt since blobs would be inferior and at the same time leading developers believe direct3d is the way to go. not to mention it would put linux in low performer class, since oss performance would be max possible. if blobs implemented it, performance would get equal, but at the same time it would deprecate gl on whole lot of fronts
    no clue about this one.
    as far as i looked the code it is pretty straight forward
    not sure about this one in whole

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •