Announcement

Collapse
No announcement yet.

The Direct3D 10/11 State Tracker Is Still Around

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by phoronix View Post
    Phoronix: The Direct3D 10/11 State Tracker Is Still Around
    So what's its state? Is there any prognosis when it will start to be useful for anything?

    Last time (quite some time ago) I tried to compile mesa with this state tracker gcc filled 8 gb ram + 8 gb swap and then the OOM killer killed it...

    Also, could it make "porting" games easier by using the wine libraries for the parts of directx that are not implemented and the direct3d state tracker for the parts it implements?

    Comment


    • #17
      d3d11 status

      Originally posted by ChrisXY View Post
      So what's its state? Is there any prognosis when it will start to be useful for anything?

      Last time (quite some time ago) I tried to compile mesa with this state tracker gcc filled 8 gb ram + 8 gb swap and then the OOM killer killed it...

      Also, could it make "porting" games easier by using the wine libraries for the parts of directx that are not implemented and the direct3d state tracker for the parts it implements?
      You can't mix the d3d state tracker and a wine implementation that's using OpenGL ...

      The status is that the D3D11 version of Unigine Heaven works via the d3d11 st's wine dlls (well, the lighting is a bit off) if:
      - you are using the nvc0 gallium driver
      - your apply a hack that passes SM4 shaders to the driver instead of generating TGSI
      - no tessellation; nvc0 implements it but it's not been tested (and extra gallium patches needed)

      The TGSI generator is partially broken and doesn't (or can't) handle all aspects of SM4 yet, and using SM4 directly only "works" with nvc0 + ugly hack.

      I tried some d3d11 games, too, but they all crash at some point. Unfortunately you can't easily debug these blobs ...

      Comment


      • #18
        Originally posted by calim View Post
        The status is that the D3D11 version of Unigine Heaven works via the d3d11 st's wine dlls
        Brilliant!

        Originally posted by calim View Post
        I tried some d3d11 games
        What games?

        Comment


        • #19
          Originally posted by elanthis View Post
          D3D is patented the same way OpenGL is. e.g., floating point textures in D3D is going to be just as much of a non-starter as it is in OpenGL.
          Or you could ignore it, and take advantage of the fact that the GPU makers already paid for that license, and because of that, if you use a GPU that already has paid the license, you are covered.
          The same could be argued for anything, meaning that the only "issue" is paranoia.

          Comment


          • #20
            Originally posted by del_diablo View Post
            Or you could ignore it, and take advantage of the fact that the GPU makers already paid for that license, and because of that, if you use a GPU that already has paid the license, you are covered.
            The same could be argued for anything, meaning that the only "issue" is paranoia.
            Except that isn't how it works. The distributor and/or user of the driver implementing the feature needs the license. As AMD/NVIDIA/Intel are not the ones distributing your Mesa RPMs/DPKGs, those drivers are not covered by any license they may have, and that is why your Gallium-based hardware drivers do not support floating point textures today despite the code already being in Mesa (it's disabled by default because of the patent). Again: this is not just for the software driver, it's for _all_ drivers in Mesa. The binary drivers are covered by whatever licenses the hardware manufacturers have because they are the distributors of the driver. Unfortunately, the driver does need to do a bit of work with the FP textures (particularly when doing format conversions and the like, which the APIs require), and so the feature is not entirely limited to the hardware.

            I'm not sure why people are being dickheads about this. The patent and legal issues are documented and known by the Mesa folks. They're documented in the actual OpenGL specification for the feature, as the patent was well known when the feature was added.

            http://cgit.freedesktop.org/mesa/mes...cs/patents.txt

            Originally posted by ChrisXY
            Also, could it make "porting" games easier by using the wine libraries for the parts of directx that are not implemented and the direct3d state tracker for the parts it implements?
            On the upside, not much of DirectX is really used much anymore. DirectInput is still around but not used much. XInput is very popular, but it would be trivial to replace that on Linux... if only the xbox gamepad driver was more feature complete (in particular, it completely lacks player identification -- it picks the player seat led on the device by literally doing a "counter=(counter+1)%4" when you plug a gamepad in). You can at least emulate the most important bits of the XInput API, or at the very least write a similar API that only takes a few minutes to port to. That's what I've done for my Linux-compatible games. DirectSound is only used by low-level audio libraries, and just about every non-trivial application uses a "real" audio API like FMOD or Wwise or Miles Sound, and sometimes OpenAL or one of the goofy little "game library" audio libs in Allegro or SDL or SFML or what have you. DirectPlay is not seen much anymore.

            The vast majority of the non-graphics Windows specific bits of modern game engines have little to do with DirectX. They're in things like the I/O layers, threading, timers, message loop, WinSock2 (the non-BSD-like parts of the API), GUI system integration, and various third-party libraries without Linux support (though those are getting pretty rare).

            Good game engines are already highly portable. They pretty much have to be in order to target the many platforms games today need to hit, most of which do not use any Windows or FOSS APIs, e.g. Nintendo and Sony consoles. [side note: No, games do not use GLES on either of those game platforms, at least not any major games; no existing Nintendo platform even supports shaders (seriously, I'm not kidding, and I wish I was) so no GLES 2 on those and Sony has GLES support but also has a proprietary API that almost all games use instead.] OS X and iOS do not use any Windows APIs, but for every FOSS-friendly API they require (OpenGL and OpenAL, basically) there's 20 proprietary Apple APIs they also require to get anything done.

            By far though the biggest impedance to Linux ports is not technology but just economics or politics. The Linux market burned game publishers in the past, the sales were never high, the piracy rate was higher than average, support costs are far higher due to the user-unfriendly nature of Linux (it's still an utter pain in the ass to actually install a third-party commercial game on Linux due to the silo/appliance model of the most popular desktop Linux distros), so the return on investment just isn't there. A small indie developer who happens to be a Linux fan or is desperate for every last sale possible might target Linux. The Big Boys just have no reason to invest much time, effort, or money at all into a few thousand extra sales on Linux when their Windows, XBox, and PS3 sales are in the millions.

            The current Humble Bundle looks to be one of the most successful, but it's got maybe 40,000 Linux sales total. At an average $10 for each Linux sale, that's a mere $400,000 from Linux users across 7 games, 2 charities, and Humble itself. If you take the default payment split, each $10 Linux sale give $6.50 to the game devs, which is less than $1 each. Before taxes, that's only $40,000 from Linux support. Now take out those taxes and dev costs, support costs, all the administrative costs of organizing and managing the Linux port... that's not much. It's probably worth it for most small indie devs (every dollar counts, there) but not in the larger game market. There are entire companies that get shut down because they're "only" making a few million in profit. The big publishers that have had Linux support in the past have only had it because they've had a few inside people who were passionate about Linux, got the sign-off from their bosses, and put in extra time to get the port out the door as an unsupported project. And most of those have stopped coming (Unreal 3 is a no-go, and we're still waiting on id Tech 5 for Linux).

            However, the fast increase in HTML5/NaCl gaming is going to help Linux a fair bit. A project I worked on over the summer works perfectly in Linux (assuming you have binary drivers installed that support the necessary level of GL features) because it just uses WebGL and JavaScript. Bastion now has a NaCl port that should work in Linux (haven't tested it yet, but I don't see why it wouldn't). More and more games are going to go that route due to a number of reasons; it's way easier to get Web games in front of potential players (only need to click a Facebook link or ad to get to it, no need to search for it in an app store or go through a multi-step install process) and for simpler games that don't need WebGL/NaCl the HTML5 model allows the games to support PC and mobile with very little extra porting effort. Basically we're getting to the point where the Open Web technologies are just beating the crap out of the proprietary Flash technologies (Stage3D is pretty crappy compared to WebGL, for instance).

            /me goes back to his current project and trying to get threaded GL texture uploading to even remotely work on Catalyst drivers

            Comment


            • #21
              Originally posted by calim View Post
              You can't mix the d3d state tracker and a wine implementation that's using OpenGL ...
              I meant taking input and sound stuff for directx from wine libs and only direct3d through this state tracker.

              Originally posted by calim View Post
              The status is that the D3D11 version of Unigine Heaven works via the d3d11 st's wine dlls (well, the lighting is a bit off) if:
              Well, thanks for the info. That sounds much more mature than anything I have heard yet (which is not much).

              Comment


              • #22
                Originally posted by elanthis View Post
                Bastion now has a NaCl port that should work in Linux (haven't tested it yet, but I don't see why it wouldn't).
                It works--even better with nouveau than the nV driver--but it's a bit slow, and sometimes it hangs when loading an area; my GPU's a bit weak (7100GS), and I probably don't have enough RAM (1.5GiB). Surprisingly, CPU load is pretty low.
                Last edited by Nobu; 12-19-2011, 11:34 PM.

                Comment


                • #23
                  Originally posted by elanthis View Post
                  /me goes back to his current project and trying to get threaded GL texture uploading to even remotely work on Catalyst drivers
                  elanthis, I always read your posts with joy. They are way more informative than anything else on this site. Just keep them going.
                  I don't know much about other AAA titles, but recently Doom3(which I bought because it was opensourced) is one of the kick ass games I have ever seen. I enjoy it more than even HL2.
                  There is very little linux specific in its engine, so I really don't understand why other games don't have ports, even unsupported ones.
                  BTW, Doom3 looks good, even on r600g. The performance is higher than I expected.

                  Comment


                  • #24
                    Thanks, for your very informative post, BUT
                    Originally posted by elanthis View Post
                    (it's still an utter pain in the ass to actually install a third-party commercial game on Linux due to the silo/appliance model of the most popular desktop Linux distros),
                    Really? The Loki installer that most of the games of the Humble Indie Bundles use seems to work pretty good. And why have it installed at all? Simply unpacking and putting a .desktop file somewhere ought to be enaugh...

                    Comment


                    • #25
                      d3d11 Games

                      Originally posted by RussianNeuroMancer View Post
                      Brilliant!

                      What games?
                      Dragon Age 2:
                      crashes somewhere in game executable after logo videos (if only I had debug info ...)

                      Civilization 5:
                      crashes too, probably because it needs deferred contexts which aren't implemented yet,
                      doing that at API capture level should be rather simple, the fast version that records GPU command buffers will be a bit more challenging

                      Skyrim:
                      doesn't even want to use d3d11, maybe it doesn't actually support it ... works with mesa/OpenGL though (looks ok but is really slow)

                      Comment


                      • #26
                        Thanks for answer
                        May you also try Deus Ex: Human Revolution later, while follow testing?

                        Comment


                        • #27
                          Originally posted by calim View Post
                          Skyrim:
                          doesn't even want to use d3d11, maybe it doesn't actually support it ... works with mesa/OpenGL though (looks ok but is really slow)
                          Originally posted by http://www.pcworld.com/article/244400/skyrim_performance_review_its_definitely_a_directx _9_game.html
                          I wasn't aware Skyrim used DirectX 9, but sure enough, it does, says HardOCP, adding that there's no DX10 or DX11 renderer, which probably sounds as strange to you, in 2011, as it does to me. Long story short, as wonderful as Skyrim's mountains can look crowned with wisps of fog or tufts of clouds, the underlying visual architecture's pretty dated, especially in terms of the way the Creation engine handles shadows. HardOCP also notes the textures tend to be more diffuse or low-res than they might have been had Bethesda designed the game with the PC in mind and not the space-limited Xbox 360 (the entire game fits, remarkably, on just one DVD).
                          Also, somebody name some Open Source directx games to help this project please!

                          Comment


                          • #28
                            I suppose the question is, is the DX11 Heaven any faster directly than via Wine or the native binary?

                            Comment


                            • #29
                              Originally posted by Drago View Post
                              There is very little linux specific in its engine, so I really don't understand why other games don't have ports, even unsupported ones.
                              Well, there's a couple reasons. First, "unsupported" does not mean "free to the publisher." There's still a ton of costs involved in a port, even if it's just things like double checking licensing and liability for posting binaries of a game using third-party paid-for libraries. A lot of engines require a licensing fee per platform the game is released on. Most games still also don't have (maintained) OpenGL renderers, and it takes time to write those. Lastly, few game developers really care; the Linux nerds I run into in the industry are much more of the "omg I just installed Ubuntu its neat talk to me about Linux" and they barely even understand the (rather vast) differences in basic dev tools on Linux compared to Windows.

                              On a related side note, I know a ton of hardcore bad-ass developer Linux nerds at Microsoft. Opposites attract or something, I guess.

                              Originally posted by ChrisXY
                              Really? The Loki installer that most of the games of the Humble Indie Bundles use seems to work pretty good.
                              They work okay. They're fragile (try installing one of those games three years from now, let's see what happens). They have a much lower chance of working if you move off the main distros.

                              Windows installers can register the app with the system so it's available for uninstallation via the OS's software manager. Windows installers can use Windows snapshotting so failed installs can be rolled back. Windows installers are guaranteed that the base GUI library and other mandatory support libraries for the OS are always available with a standard ABI. Windows installers don't need users to set executable bits to run them. Windows installers can bundle optional system libraries so they get installed if they're not available**. Even little things matter, like how a Windows installer .exe can have an icon embedded in it that the desktop file-manager or browser can show, while the .sh/.bin packed installers on Linux cannot.

                              ** Admittedly, doing things the Linux way and asking the OS to install them would be better, but last I checked MojoSetup/Loki_setup could not do that, and for good reason since not every distro is guaranteed to have every library the game might need, so Linux games take a step backward from even Windows' DLL hell and statically link or "locally bundle" libraries that otherwise have stable ABIs and belong on the system.

                              The Linux software installation scene is still just totally whacked. My particular favorite is when somebody follows a link to some clearly Linux-friendly FOSS software like the Gimp and then they go to download it for Linux and LOL! they just get a source .tar.gz and what the hell are they supposed to do with that? Nobody in Linux land seems to have realized yet that users find software by links in blog articles or Google or email and visiting the completely OS/distribution-agnostic homepage for said software. Not by opening "Applications -> System Tools -> Software Package Repository Viewer 2.14.3" and then browsing categories like "Application/Desktop/Graphics/Raster" and then wading through options like "gimp-docs", "gimp-libs", "gimp-common", "gimp-tools", "gimp-pulp-fiction", "gimp-desktop", "gimp-scripts", etc.

                              In the App Store scene, likewise users still aren't browsing around looking for specific apps. Angry Birds is not popular because users are hearing about it and then looking it up on their phone's app store. Angry Birds is popular because bored users open the app store games to see if anything there looks interesting, seeing Angry Birds at the top of the list with 5 stars after 450,000 reviews, and then installing it because it looks fun. Likewise on Steam, relatively few people hear about a game and then go look for it there. Most of the sales come from users opening Steam, seeing the giant banners in the main store page with the "75% off!" pricing and impulse buy. These companies _also_ sell in other channels so that TV advertising works (most TV advertising accounts for sales in brick-and-mortar stores) and Web advertising works (usually by linking directly to a product in an online store like Amazon or some such). Point is that the approach where Fedora is trying to build their own little distro-specific app store silo is not going to do any good at all for companies making games and trying to sell them because they aren't hitting any of the target demographics for app stores and also aren't hitting any of the target demographics for web stores or brick-and-mortar stores. The FOSS software that can ever end up in their silo are not things that people "impulse install." They're not solving the problems of finding and installing desktop software. The Ubuntu Store might work out since it allows proprietary software, and devs might start releasing into that, but then we're stuck in a world where the only distro that can play commercial games is Ubuntu because the other distros didn't want to play ball and build a larger, open, neutral platform to compete.

                              This is again one of the reasons why classically Flash and now HTML5 and NaCl are so appealing to developers: the app/game literally is a web page so there's no need to ever install anything or find an OS-specific icon to click or anything else. Follow link, app loads, done. On Windows, it's almost that easy for native apps, and is likely just going to get easier come Windows 8 and the new app store. Which I'd expect them to focus on, because the last thing the dominate OS vendor wants is for traditionally native-only apps to move to an OS-neutral platform like the Web.

                              I get so upset about the Linux installer topic in particular because it's (almost trivially) FIXABLE. It's just the distro engineers having their damn heads lodged so far up their asses that they can lick the lining of their own stomaches. Bunch of political shenanigans, intense NIH syndrome, and fear-induced bullcrap. I'm not even talking about just hitting parity with Windows, but it could be done so much _better_ than Windows if only the distros weren't in the way.

                              Originally posted by ChrisXY
                              And why have it installed at all? Simply unpacking and putting a .desktop file somewhere ought to be enaugh...
                              You're right. That sounds so much easier than clicking an Install icon and having it Just Work all by itself. Why didn't I think of that?

                              I've spent the years using Linux-Fu to install apps and work around bad UIs and fix obvious bugs and make a server OS feel like a cheap desktop OS and generally get things working, and felt proud of myself on how skillful and awesome I was. After 10 years of that crap, eventually you realize you just don't care anymore and just want it to work when you click the icon, because given the choice between screwing around with installers or doing something actually fun, guess which one wins out once the novelty of Linux wears off?

                              Obligatory XKCD comic:

                              Comment


                              • #30
                                I am 200% with elanthis here. I think users allready have to do this Disctro-natural-selection, and Linux distributions ( at least desktop ones), should reduce to 3-4, with interoperatable package system. I like Ubuntu, but it as I am pedantic, I don't use it. I just don't get why there are so many unnescessary services running (like cups without a printer attached, bluez stack without blue-tooth device, even python is running. For that reason I use Arch, but eventually for the cause I can switch to Ubuntu

                                PS: I Ubuntu you can download a package file (.deb), and istall it with the installer. It will resolve all needed dependancies.

                                Comment

                                Working...
                                X