Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 36

Thread: The Direct3D 10/11 State Tracker Is Still Around

  1. #11
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    Quote Originally Posted by 3vi1 View Post
    I must be reading that wrong. Haven't they both support floating point textures for like seven years now?
    Microsoft owns the patents (previously owned by SGI), so obviously D3D is in the clear.

    The OpenGL specification includes some patented technology. It's more accurate really to state that modern computer graphics are founded on some technologies that are patented, and any and all graphics APIs worth using are going to rely on implementations licensing or violating those patents.

    This is one of the reasons why your Open Source Linux drivers on mainstream distros are going to be indefinitely stuck on OpenGL 2.1.

    This is a pretty well known fact and frequently mentioned topic on the boards here. I take it you're new. Welcome.

  2. #12
    Join Date
    Apr 2011
    Posts
    405

    Default

    Quote Originally Posted by elanthis View Post
    It's more accurate really to state that modern computer graphics are founded on some technologies that are patented, and any and all graphics APIs worth using are going to rely on implementations licensing or violating those patents.
    That sounds like a page out of the MPEG Cartel/Crapple's playbook. "It's illegal for other codecs to compete without giving us a cut, but we're not going to say it like that because we don't want the DOJ and EC sniffing around"

    Ding ding. Ding ding. Stop and pay the troll. Innovation Tax time.

    I should probably also state that patents like these are how companies like Microsoft and Apple kick their feet up and relax on a pile of legacy software. As long as nobody can compete without violating their patents, where's the incentive to do better?
    Last edited by DaemonFC; 06-04-2011 at 07:11 AM.

  3. #13
    Join Date
    Oct 2008
    Posts
    109

    Default

    Quote Originally Posted by elanthis View Post
    This is a pretty well known fact and frequently mentioned topic on the boards here. I take it you're new. Welcome.
    No. I just usually quit reading discussions when they degrade to FUD.

    Presumably, the implementation of floating point textures would be done by the graphics driver or the card firmware, not the state tracker - so this is a non-issue anyway.

  4. #14
    Join Date
    Aug 2009
    Location
    Russe, Bulgaria
    Posts
    485

    Default

    Couldn't for instance Mesa3D gets so optimized so for instance AMD decides it will be the official driver for windos as well. Like their new driver for windos embedded. This D3D state-trackers will be put to good use then.

  5. #15
    Join Date
    Sep 2010
    Posts
    568

    Default

    Problem with patents is that patent holder may require license from each and every OS shipped.

    So unless distribution maker (and there are lots of them) get license to cover its customer's too, OEMs (and there are lots of them) would have to step in and pay for the licenses.
    Too much for basically free (as free beer) OS.

  6. #16
    Join Date
    Jun 2010
    Location
    ฿ 16LDJ6Hrd1oN3nCoFL7BypHSEYL84ca1JR
    Posts
    969

    Default

    Quote 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?

  7. #17
    Join Date
    Feb 2011
    Posts
    67

    Default d3d11 status

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

  8. #18

    Default

    Quote 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!

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

  9. #19
    Join Date
    Jun 2011
    Posts
    78

    Default

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

  10. #20
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    Quote 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

    Quote 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

Posting Permissions

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