Linked by Thom Holwerda on Tue 21st Sep 2010 21:11 UTC, submitted by Michael
3D News, GL, DirectX "Luca Barbieri made a rather significant commit today that adds a state tracker dubbed 'd3d1x', which implements the Direct3D 10/11 COM API in Gallium3D. Luca says this is just the initial version, but it's already working and can run a few DirectX 10/11 texturing demos on Linux at the moment. This is not a matter of simply translating the Direct3D calls and converting them to OpenGL like how Wine currently handles it, but is natively implemented within Gallium3D and TGSI to speak directly to the underlying graphics driver and hardware. Thanks to Gallium3D's architecture, this Direct3D support essentially becomes 'free' to all Linux drivers with little to no work required."
Order by: Score:
Comment by Kasi
by Kasi on Wed 22nd Sep 2010 00:27 UTC
Kasi
Member since:
2008-07-12

Now this, this is sweet.

Reply Score: 3

Dunno about this...
by Kivada on Wed 22nd Sep 2010 05:21 UTC
Kivada
Member since:
2010-07-07

Sounds like it'll ensure that fewer and fewer games will be made in OpenGL if this gets good...

Reply Score: 2

RE: Dunno about this...
by Drumhellar on Wed 22nd Sep 2010 05:51 UTC in reply to "Dunno about this..."
Drumhellar Member since:
2005-07-12

If D3D is kept current on Linux, is that a problem? OpenGL doesn't lead in anything anymore, and only plays catch-up to Direct3d.

Both nVidia and AMD design their graphics chips around the next Direct3D spec, and after the chips are finalized, the OpenGL spec is updated.

Reply Score: 3

RE[2]: Dunno about this...
by kaiwai on Wed 22nd Sep 2010 09:43 UTC in reply to "RE: Dunno about this..."
kaiwai Member since:
2005-07-06

If D3D is kept current on Linux, is that a problem? OpenGL doesn't lead in anything anymore, and only plays catch-up to Direct3d.

Both nVidia and AMD design their graphics chips around the next Direct3D spec, and after the chips are finalized, the OpenGL spec is updated.


I would argue that OpenGL and DirectX cater for two entirely different markets. When there was going to be a massive overhaul to OpenGL the people who kicked up the stink about it? the CAD industry wanted to keep the status quo and the gaming industry wanted to have a whole heap of new features and ways of doing things. The result is an API designed by a committee trying to cater for a variety of different needs versus DirectX which is controlled via a benevolent dictator who makes decisions and the market follows. The benefit of the later over the former is uniformity and a set direction that isn't swayed by protests from those sitting on the cheap seats.

With that being said OpenGL has made a huge leap forward over the last couple of years - it hasn't been give the massive changes that some have been hoping for it but it certainly hasn't been standing still when you consider what has appears in OpenGL 4.x.

Reply Score: 3

RE[3]: Dunno about this...
by gnufreex on Thu 23rd Sep 2010 06:37 UTC in reply to "RE[2]: Dunno about this..."
gnufreex Member since:
2010-05-06

Microsoft... Benevolent? Are you serious?

As for OpenGL playing catchup..? On what planet? It is other way around.

Reply Score: 3

RE[4]: Dunno about this...
by Timmmm on Sat 25th Sep 2010 14:51 UTC in reply to "RE[3]: Dunno about this..."
Timmmm Member since:
2006-07-25

As for OpenGL playing catchup..? On what planet? It is other way around.


On this planet. New OpenGL versions regularly add features already in Direct3D.

Reply Score: 2

RE[2]: Dunno about this...
by maty on Wed 22nd Sep 2010 10:52 UTC in reply to "RE: Dunno about this..."
maty Member since:
2010-09-22

I would suggest you to read the following blogposts. You may reconsider your point of view afterwards...

http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-and-not-D...

http://blog.wolfire.com/2010/08/OpenGL-update

Also take note that WebGL has the potential to make Flash history. There will be no need to install a buggy Flash plugin on Linux when websites use jQuerry, when video sites use the HTML5 video tag, and when online games use WebGL. For instance, look at this:
http://playwebgl.com/games/quake-2-webgl/

Reply Score: 4

RE[3]: Dunno about this...
by Neolander on Wed 22nd Sep 2010 11:31 UTC in reply to "RE[2]: Dunno about this..."
Neolander Member since:
2010-03-08

Very interesting read ;) Who would have known that game devs know so much about graphic apis, instead of just choosing some framework and taking the graphic api which comes with it ?

Reply Score: 3

RE[3]: Dunno about this...
by Drumhellar on Wed 22nd Sep 2010 16:56 UTC in reply to "RE[2]: Dunno about this..."
Drumhellar Member since:
2005-07-12

A couple issues with the linked article.

First, Half the article is about FUD, and not technology. 4 year old FUD, no less. He talks about when Microsoft was originally planning to disable direct hardware access to graphics without Direct3D. This was a long time ago.

The PS3 uses it's own API for 3D, and while Sony does provide OpenGL ES 2.0, it is poorly supported and offers low performance. I don't believe the Nintendo supports OpenGL on the Wii, though their native API is OpenGL-like.

While OpenGL is cross-platform, he he misrepresents OpenGL ES as part of it. OpenGL ES has been a separate API, not just a subset as commonly described. Its inclusion in OpenGL 4.1 is recent.

His stats on XP use being dominant are outdated, as the graph he links to shows 56% of Steam users have a DirectX 10-class GPU running Windows 7/Vista. This is not his fault, though. However, he overstates the importance of XP's user base, and ignores the fact that it is shrinking.

His initial claims about OpenGL being a significantly faster API are later refuted by himself when he says "Microsoft has worked hard on DirectX 10 and 11, and they're now about as fast as OpenGL..."

Microsoft has indeed done a ton of work on bringing Direct3D execution up to speed.

While tessellation may have been available as an extension to OpenGL for three years, that isn't the same as being part of the spec. Microsoft wisely removed the ability for hardware manufacturers to add custom extensions. Software developers no longer have to target D3D + vendor extensions for full capability, as they do with OpenGL. Having to support various extensions from different hardware vendors kinda defeats the purpose of a universal API.

Tessellation has also been quite possible through the standard Direct3D 10 pipeline. Only now there is a standard feature.

I must also add that tessellation was available as a direct3D 6/7 extension provided on ATI's Radeon II graphics chip (Yes, the successor to the original Radeon). Nobody used it, and the dropped the feature in hardware.

They mention Blizzard developing and releasing Mac games simultaneously for Windows and MacOS. This is intellectual dishonesty on the case of the author. I'm sure he knows that Blizzard uses Direct3D for the Windows ports. This is a very dishonest representation.

I wonder if he even read the John Carmack quote he included: "It’s still OpenGL, although we obviously use a D3D-ish API [on the Xbox 360], and CG on the PS3. It’s interesting how little of the technology cares what API you’re using and what generation of the technology you’re on."

From the quote, the author concludes, "If you can hit every platform using OpenGL, why shoot yourself in the foot by relying on DirectX?" Did he not see that Mr. Carmack said he used the Xbox API for the Xbox, and CG for the PS3? That certainly isn't hitting every platform with OpenGL.

And, while we're quoting John Carmack, since it is a popular thing to do:

…DX9 is really quite a good API level. Even with the D3D side of things, where I know I have a long history of people thinking I'm antagonistic against it. Microsoft has done a very, very good job of sensibly evolving it at each step—they're not worried about breaking backwards compatibility—and it's a pretty clean API. I especially like the work I'm doing on the 360, and it's probably the best graphics API as far as a sensibly designed thing that I've worked with.


Don't get me wrong. I have nothing against OpenGL. I think these OpenGL vs Direct3D wars are stupid. There is enough room on the planet for more than one graphics API. I am just opposed to the if-its-MS-its-bad attitude that much of these debates are based on.

Reply Score: 5

RE[4]: Dunno about this...
by phoudoin on Wed 22nd Sep 2010 17:12 UTC in reply to "RE[3]: Dunno about this..."
phoudoin Member since:
2006-06-09

"I am just opposed to the if-its-MS-its-bad attitude that much of these debates are based on."

What about the if-its-single-platform-its-bad attitude?
Isn't a valid argument on a website talking about operating systemSSSSS?

Reply Score: 4

RE[5]: Dunno about this...
by Drumhellar on Wed 22nd Sep 2010 20:07 UTC in reply to "RE[4]: Dunno about this..."
Drumhellar Member since:
2005-07-12

Good point. The single-platform-is-bad attitude is valid, and I would tend to agree.

However, the article you had linked to is clearly in the bad-because-its-Microsoft vein. A significant portion of the cross-platform nature of OpenGL is misrepresented.

Prior to OpenGL 4.1, your OpenGL ES code wouldn't work in OpenGL implementations, and vice versa. He also implies that part of Blizzard's success as a multi-platform gaming developer is due to OpenGL's cross-platform nature. However, it has little to do with OpenGL, as they only use OpenGL code for MacOS X. Their Windows games are coded using D3D.

In John Carmack's comments about OpenGL, his statements about using the native toolkits for the console versions of Rage were completely ignored, and his statement was still used to support the cross platform benefits of OpenGL. Also, I do believe the quote I found from Mr. Carmack may be from the same interview (I don't have flash, so I can't watch the video). If so, the author is committing blatant intellectual dishonesty.

Also, the author completely misses the key benefit of OpenGL (and, it's key weakness, depending on your requirements): It's stability of API. Old OpenGL code will continue to work as a first-class citizen for a long while, and not just a separate code path just for compatibility's sake.

Reply Score: 2

RE[2]: Dunno about this...
by phoudoin on Wed 22nd Sep 2010 16:50 UTC in reply to "RE: Dunno about this..."
phoudoin Member since:
2006-06-09

OpenGL still leads in being open *and* multiplatform.
Plus I see no Direct3D based games for the smartphones, but more and more OpenGL ES ones...

Reply Score: 3

RE[2]: Dunno about this...
by Kivada on Thu 23rd Sep 2010 10:08 UTC in reply to "RE: Dunno about this..."
Kivada Member since:
2010-07-07

You forget that non native games for OS X and Linux run terribly slow when compared to the native client, should one exist.

Also, why should anyone have to buy a new, slower OS just for the graphics stack when their current OS is still working fine and is still supported with security updates? Sure 64 bit allocation, but most gamers are not on the upgrade treadmill, only the enthusiast crowd is and they make up less then 1% of the market.

The vast majority are still running IGPs or a low end card that came with their OEM box. There are also many that build a upper mid range box once every 5 years or so. at the time of buying a new machine is when they bother to upgrade their windows.

Reply Score: 1

Neolander
Member since:
2010-03-08

...because actually implementing a full up-to-date D3D layer which people can use would be nearly impossible, due to...
-Copyright infrigement
-MS's ability to break the API every year, requiring the Gallium3D people to start over
-Speed (Wine recompiles programs first, but if I understand well this is about real-time translation, aka the main reason why old interpreters deeply suck)

Reply Score: 1

Drumhellar Member since:
2005-07-12

MS can't easily just change the API. A huge amount of third party software depends on it, and it is tied fairly closely to existing (and future) hardware.

You must realize that graphics hardware is designed around the requirements of whatever the next version of DirectX is, and DirectX is tied fairly well to the hardware. It isn't developed in a vacuum; hardware manufacturers are deeply involved in the spec, and if Microsoft were to start changing things willy nilly just to irk a handful of Linux users, AMD and nVidia would probably start supporting OpenGL more. Microsoft surely wants that much, much less than no DirectX on Linux.

As for speed, no interpretation is involved.
IIRC it works like this: The API is written on gallium, and gallium is in turn implemented for the specific hardware. Since DirectX is being implemented via Gallium3D, it is a fully-native API.

Edited 2010-09-22 06:12 UTC

Reply Score: 7

fithisux Member since:
2006-01-22

You must realize that graphics hardware is designed around the requirements of whatever the next version of DirectX is, and DirectX is tied fairly well to the hardware.


That is not true. If that was true all cards should provide a common HW interface and Windows should have one driver "DirectX device" like USB Mouse not several drivers.

Reply Score: 1

Drumhellar Member since:
2005-07-12

Designing hardware for common requirements is not at all equal to designing hardware to a common interface.

Example. Direct3D 11 needs feature X.
ATI implements Feature X by implementation Y.
However, nVidia implements Feature X, but believes Implementation Z is more suited for the rest of their graphics pipeline.

DirectX is agnostic to the actual implementation, as long as the feature returns the same results. This allows hardware manufacturers to tune their hardware different ways.

Reply Score: 2

lemur2 Member since:
2007-02-17

...because actually implementing a full up-to-date D3D layer which people can use would be nearly impossible, due to... -Copyright infrigement


The software in question is a "thin layer over the Gallium 3D driver layer". In turn, the Gallium3D driver is a part of the Linux kernel (which includes hardware drivers either directly or as kernel loadable modules). None of this is in any way a copy of any Microsoft software. There is no "copy and paste" here, this is a new implementation of the Direct3D API. Therefore, no copyright infringement can occur.

-MS's ability to break the API every year,


MS won't break the API unless they wish to break games.

requiring the Gallium3D people to start over


How so?

-Speed (Wine recompiles programs first, but if I understand well this is about real-time translation, aka the main reason why old interpreters deeply suck)


It is a software layer interfacing via an API to client programs on the one side and on the other side to different physical hardware cards via a common intermediate shader language. I can't see where that is a speed-challenged interpreter.

http://www.phoronix.com/forums/showpost.php?p=148860&postcount=21
AFAIK the state_tracker uses different states of a graphic pipeline and the TGSI shader language to implement different things in e.g. a OpenGL or another state_tracker.

Every g3d hardware drivers should be able to handle TGSI shader language and different states common in a graphic pipeline.

So when you use a state_tracker, it just hooks itself to a hardware-driver able to use TGSI and different states. This will able different state_trackers work on different g3d hardware drivers.


http://en.wikipedia.org/wiki/Gallium3D
The Gallium3D library operates as a layer between the graphics API and the operating system with the primary goal of making driver development easier, bundling otherwise duplicated code of several different drivers at a single point (this is done by providing a better division of labor, for example, leaving memory management to the kernel DRI driver) and to support modern hardware architectures.


In the sense of it being a layer between the graphics API and the operating system, this Direct3D state tracker for Gallium3D is no different in principle from Direct3D software from Microsoft sitting between the Direct3D API and the operating system (in that case Windows). Indeed, it isn't really any different from an OpenGL state tracker, apart from presenting a different API to client programs.

This new Gallium3D state tracker implementing a Direct3D API on Linux is equivalent functionality to, but entirely different code from, the Direct3D API driver software for Windows.

http://www.phoronix.com/forums/showpost.php?p=148848&postcount=13

Quote: How is this possible?

What do you mean? It's just an API. Just like OpenGL.

Quote: Physically and legally?

Physically: by using a keyboard to write code.
Legally: by writing your own header files for the API instead of copying them from Microsoft's DirectX SDK.


I hope this information helps.

Edited 2010-09-22 07:07 UTC

Reply Score: 5

Neolander Member since:
2010-03-08

The software in question is a "thin layer over the Gallium 3D driver layer". In turn, the Gallium3D driver is a part of the Linux kernel (which includes hardware drivers either directly or as kernel loadable modules). None of this is in any way a copy of any Microsoft software. There is no "copy and paste" here, this is a new implementation of the Direct3D API. Therefore, no copyright infringement can occur.

Can't microsoft patent some mechanism used in Direct3D, like e.g. tesselation ? Is it really only implementation that can be patented ?

MS won't break the API unless they wish to break games.

Indeed. Owning the proprietary spec, they can, however, make the API much more complex at each release, meaning that Linux players won't be able to play latest games for some time. Or they can link it with windows-specific technology like .net as much as possible. Kinda the same problem as reimplementing the Flash spec.

"requiring the Gallium3D people to start over"

How so?

Sorry, I meant the part of the G3D project which works on reimplementation of D3D

Reply Score: 2

WereCatf Member since:
2006-02-15

Can't microsoft patent some mechanism used in Direct3D, like e.g. tesselation ? Is it really only implementation that can be patented ?

Tessellation is too general a method to be patented. And it's not even an algorithm or anything, it's just an action of doing something. Think of building a house: you can patent a specific way of building a specific kind of a house but you can't patent the whole idea of building a house. So no, Microsoft can't patent it.

Indeed. Owning the proprietary spec, they can, however, make the API much more complex at each release, meaning that Linux players won't be able to play latest games for some time.

Of course that's true, but D3D is aimed at the whole gaming and 3D graphics industry so if Microsoft were to add unnecessarily complex stuff in it no one would use them and D3D would lose a lot of its popularity. Microsoft can't just go and make D3D more complex like that. Besides, it'd most likely also slow it down if they were to do such a thing, so that's yet another no-go.

Besides, even if DX12 was incompatible with DX11 it doesn't mean Linux folks would make it so: they'd just keep the existing DX11 layer and add a DX12 one in addition to it, not replace it, and thus you'd be able to run both. But again, Microsoft would be insanely stupid to go that route. They'd just annoy billions of their users, and not only gamers but also high-class enterprise users.

Or they can link it with windows-specific technology like .net as much as possible. Kinda the same problem as reimplementing the Flash spec.

Linking it with something like .NET or something would be a better way from Microsoft's view, but again, what benefit would that bring to DirectX developers or users? Would it be of so much benefit that it would be useful, or would it just slow DirectX down or add hurdles that would turn developers away instead?

Reply Score: 3

Neolander Member since:
2010-03-08

Of course that's true, but D3D is aimed at the whole gaming and 3D graphics industry so if Microsoft were to add unnecessarily complex stuff in it no one would use them and D3D would lose a lot of its popularity.

Stuff that's complex to implement is not necessarily complex to use. Take malloc(), as an example : incredibly handy and easy to use, but that certainly does not mean that memory management is a trivial thing to implement.

What could prevent Microsoft from implementing things like this in D3D ? It could take them some time, but they could keep the spec only available to trusted commercial partners during this time and only unveil it when the new release of D3D has reached beta quality...

Microsoft can't just go and make D3D more complex like that. Besides, it'd most likely also slow it down if they were to do such a thing, so that's yet another no-go.

Except with Vista where the abuse was noticed, Microsoft and Intel constantly made people buy more and more powerful hardware for tasks which they could do on a PIII as time passed, and they never complained. Without the Windows monopoly, computers for office work could cost half less than they do now. Also, do you really think that Crysis being bloated prevented many players from buying it ?

Besides, even if DX12 was incompatible with DX11 it doesn't mean Linux folks would make it so: they'd just keep the existing DX11 layer and add a DX12 one in addition to it, not replace it, and thus you'd be able to run both. But again, Microsoft would be insanely stupid to go that route. They'd just annoy billions of their users, and not only gamers but also high-class enterprise users.

Indeed, they could, that's what Microsoft did with DX10 on Vista.

Linking it with something like .NET or something would be a better way from Microsoft's view, but again, what benefit would that bring to DirectX developers or users? Would it be of so much benefit that it would be useful, or would it just slow DirectX down or add hurdles that would turn developers away instead?

Actually, many people love .net and C#. I don't use it myself so I can't tell why, but I'm sure that someone who uses it daily like nt_jerkface can tell you why that technology is so great. If microsoft did it right, developers could actually enjoy the thing instead of seeing it as an unnecessary and anticompetive hurdle.

Reply Score: 3

WereCatf Member since:
2006-02-15

Stuff that's complex to implement is not necessarily complex to use. Take malloc(), as an example : incredibly handy and easy to use, but that certainly does not mean that memory management is a trivial thing to implement.

Not necessarily, but likely. And I just don't really know how they could do something that's really useful yet so god damn hard to implement that even people who have written a whole 3D acceleration system and drivers from scratch wouldn't be able to implement..

Actually, many people love .net and C#. I don't use it myself so I can't tell why, but I'm sure that someone who uses it daily like nt_jerkface can tell you why that technology is so great. If microsoft did it right, developers could actually enjoy the thing instead of seeing it as an unnecessary and anticompetive hurdle.

Indeed, many people do love .NET and C#. But DirectX is supposed to be useable even from plain C/C++ applications, not just .NET applications, so tacking .NET as a requirement to DirectX would not really be of any benefit per ce. DirectX is perfectly useable in .NET applications as-is, so the only way Microsoft could tack .NET as a requirement would be to either do DirectX itself in .NET or allow only .NET applications to use it. And that still wouldn't change a thing.

Reply Score: 2

Neolander Member since:
2010-03-08

Not necessarily, but likely. And I just don't really know how they could do something that's really useful yet so god damn hard to implement that even people who have written a whole 3D acceleration system and drivers from scratch wouldn't be able to implement..

Don't know if it's even likely, most low-level OS tasks are about putting a simple interface on top of a complex mechanism...
About things nice to use and hard to implement, well, let's imagine something which automatically shades an object's texture in order to make this object look like it has more vertexes in it (I think this is pretty much how bump-mapping works). A simple interface would be two give two 3D models, one that is used for display work, and one that is used for lighting. Hardware functionnality is unchanged, all is done using shader languages. This is simple for devs and hw manufacturers, but making the whole thing less power-crunching on the implementation side would be quite hard.

Indeed, many people do love .NET and C#. But DirectX is supposed to be useable even from plain C/C++ applications, not just .NET applications, so tacking .NET as a requirement to DirectX would not really be of any benefit per ce. DirectX is perfectly useable in .NET applications as-is, so the only way Microsoft could tack .NET as a requirement would be to either do DirectX itself in .NET or allow only .NET applications to use it. And that still wouldn't change a thing.

Well, I don't know enough about .Net to go into technical discussions, but I'm sure it has some handy features that are likeable for game devs. Making all examples of the direct3D doc using these features could be a good start. It would be advertised as "making the DirectX doc cleaner, with code that's easier to understand". I can see some benefit for devs here.

Edited 2010-09-22 12:01 UTC

Reply Score: 2

nt_jerkface Member since:
2009-08-26


Indeed, many people do love .NET and C#. But DirectX is supposed to be useable even from plain C/C++ applications, not just .NET applications, so tacking .NET as a requirement to DirectX would not really be of any benefit per ce.


I disappear for 2 days and my name still appears in a thread related to .net. Hmmm.

Anyways the main problem with tying DX to .net is that all the main 3D engines are written in C++. These codebases are massive and MS would risk a major backlash if they tied their next console to .net. There is no way they would risk ceding those developers to Sony or Nintendo just to prevent a few Linux game ports.

But what they can do is tie their own game development environment to .net as they partially do with XNA. So while DX stays neutral the productivity increase of using .net offsets the financial benefit of targeting alternative platforms.

Reply Score: 2

_txf_ Member since:
2008-03-17

Codebases aside there is no way that they would force people to use .net . A lot of games esp. non-indie/small Developers would never use .net. It just does not provide the control over hardware necessary to optimize code (can you even put inline assembler in .net?).

It certainly is more elegant and easy to program than c++ and thus is good for those than don't have such strict performance requirements. And it is true that bad c++ code can run slower than .net, but I don't think that game devs with budgets of millions would hire bad coders.

Reply Score: 2

_txf_ Member since:
2008-03-17

Indeed, they could, that's what Microsoft did with DX10 on Vista.


Whilst it may seem like microsoft did this just to force people to upgrade, they had valid technical reasons to force vista usage.

First, DX9 vas pretty much an evolution of DX7, DX10 was quite a bit different architecturally and did not have backwards compatibility.

Second, DX10 required recent gpus

Third in order to reduce maintenance they decided to target only vistas new driver model,instead of maintaining to different versions of DX10. I don't know how the gpu manufacturers felt about this seeing as they would be the ones having to develop pre vista drivers exposing DX10, which did not have any uptake from games or applications.

Reply Score: 3

Drumhellar Member since:
2005-07-12

D3D merely exposes hardware feature in a consistent way.

I know you listed it only as an example, but hardware tessellation speficially existed on the Radeon 2, and was available through ATI's extensions to DirectX 6 (maybe 7?) and OpenGL 1.2. It was later removed because it was rarely used. The concept of tessellation has been implemented for a long time. Note that the computer generated landscape for the Genesis video in "ST: Wrath of Kahn" utilized a form of iterative tessellation + fractals to generate it, and I'd bet tessellation algorithms have changed little since then.

As for making it more complex at each release, that would be counter productive. It would make it harder to implement for their hardware partners (nVidia, AMD, and Intel), and make it harder for programmers to use, encouraging a switch to OpenGL. If anything, Microsoft would embrace a quality port of DirectX, because it would further strengthen their influence on hardware makers as well as graphics developers.

Instead of leveraging DirectX to kill Linux, they'll use DirectX on Linux to encourage more Windows development. This avoid bad PR, makes them appear more open, and attracts developers, all while avoiding damaging their own product.

I think you're just getting hung up on the fact that it is a Microsoft technology, and thus inherently evil.

Reply Score: 3

Neolander Member since:
2010-03-08

D3D merely exposes hardware feature in a consistent way.

So hardware vendors fully control D3D features in the end, and Microsoft can't use its control of the D3D specs in any way ? They can't block some hardware features or make them easier to implement in a specific way ? That sounds strange, how is the association of SW and HW vendors around D3D and OpenGL a partnership then ? Why don't SW vendors tell HW vendors to make the spec themselves ?

As for making it more complex at each release, that would be counter productive. It would make it harder to implement for their hardware partners (nVidia, AMD, and Intel), and make it harder for programmers to use, encouraging a switch to OpenGL.

There isn't a single kind of complexity, again. As malloc() shows, it's possible to create features that are complex to implement for OS vendors, but require little to no work from HW manufacturers and programmers. Consider that memory allocation does not even require memory protection or linear address translation to work, those HW features just make it safer or more efficient. Can't MS introduce *that* kind of complexity in D3D safely ?

If anything, Microsoft would embrace a quality port of DirectX, because it would further strengthen their influence on hardware makers as well as graphics developers. (...)

Again, how is such an influence useful if D3D is simply a mirror of hardware capability ? What would be the benefit from them ?

Also, could you explain how helping DirectX to be ported on other OSs encourages Windows development ? To me, it seems like Microsoft losing an exclusive advantage on its competitors.

I think you're just getting hung up on the fact that it is a Microsoft technology, and thus inherently evil.

Not exactly. I'm more generally cautious about big companies. Being companies, their first goal is to make money on a market of limited size, no matter how, which is a proven source of morally questionable actions. Being big, they have much power, and such power has a great abuse potential. My (maybe paranoid) position is hence that one should look for every possible way things can go wrong when they are around, before admitting that everything is actually okay.

Then, of course, there are some companies which I *like* more than others, due to positive or negative experience with them, which means that I'm more or less cautious about them. As an example, I'm much more cautious about Microsoft and Apple than I am about Nokia, Samsung, or Adobe, because I've seen more crap coming from the formers than the latters.

Edited 2010-09-22 09:37 UTC

Reply Score: 3

lemur2 Member since:
2007-02-17

"D3D merely exposes hardware feature in a consistent way.

So hardware vendors fully control D3D features in the end, and Microsoft can't use its control of the D3D specs in any way ? They can't block some hardware features or make them easier to implement in a specific way ? That sounds strange, how is the association of SW and HW vendors around D3D and OpenGL a partnership then ? Why don't SW vendors tell HW vendors to make the spec themselves ?
"

If a feature is embedded in hardware, then anyone who legally purchases the hardware has a license to use the features embedded within it.

There is no requirement that a particular brand of software (from another company) must be used to access the features of the card. The purchase contract for the card is a contract between the card manufacturer and the buyer of the card.

For a software vendor third party to try to interfere in that contract between hardware vendor and hardware purchaser would be an act of tortious interference, would it not?

http://en.wikipedia.org/wiki/Tortious_interference

For the hardware vendor to require that the card purchaser must use only the products of a third party would be a case of product bundling, would it not?

http://en.wikipedia.org/wiki/Product_bundling

Surely you wouldn't suggest that Microsoft would indulge in illegal practices such as these?

Reply Score: 2

lemur2 Member since:
2007-02-17

Also, could you explain how helping DirectX to be ported on other OSs encourages Windows development ? To me, it seems like Microsoft losing an exclusive advantage on its competitors.


OpenGL is an API that is available on every platform. On Windows it has abysmal performance, but everywhere else it is fine.

Until now, Direct3D was a Windows-only API.

If a software developer were to write code to the Direct3D API, then their code used to be chained to Windows.

OTOH, if a software developer wrote code to the OpenGL API, then their code can run on a vast array of platforms with only a re-compile. It perhaps wouldn't run that well on Windows, but that is a Windows problem, not an OpenGL problem.

Now, however, if Gallium3D becomes a commonly available driver for Linux, then code written to the Direct3D API would suddenly become far easier to port to non-Windows platforms via a relatively painless re-compile.

This expansion of the market into which developers could feasibly sell their software would make it more viable for them to write software to the Direct3D API.

Reply Score: 3

lemur2 Member since:
2007-02-17

If a software developer were to write code to the Direct3D API, then their code used to be chained to Windows.

...

OTOH, if a software developer wrote code to the OpenGL API, then their code can run on a vast array of platforms with only a re-compile.


Why did that get modded down?

I'm not kidding here or pulling anyone's leg.
http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-and-not-D...
When we tell graphics card representatives that we use OpenGL, the temperature of the room drops by ten degrees.

...

OpenGL is supported on every gaming platform, including Mac, Windows, Linux, PS3 (as a GCM wrapper), Wii, iPhone, PSP, and DS. Well, every gaming platform except for the XBox

...

Microsoft initiated a fear, uncertainty, and doubt (FUD) campaign against OpenGL around the release of Windows Vista.

...

Wouldn't it be more profitable to ditch it and use DirectX like everyone else? No, because in reality, OpenGL is more powerful than DirectX, supports more platforms, and is essential for the future of games.


It is not just me who points out facts like these. I do have backup.

Reply Score: 3

saynte Member since:
2007-12-10

You maintain that the OpenGL performance on Windows is abysmal. The last OpenGL game I played on both Linux and Windows seemed to be fine, please see

http://www.anandtech.com/print/1509

I realize it is dated (2004), but this was the last "big" game that I remember playing on Linux (maybe Quake 4, but it should be the same engine). The link shows that Windows version is consistently faster, sometimes almost 2x, than the Linux one. It would be surprising to find that performance has dropped so far as to be qualified as 'abysmal'.

Do you have some data to show that performance on Windows is so bad?

Reply Score: 1

lemur2 Member since:
2007-02-17

You maintain that the OpenGL performance on Windows is abysmal. The last OpenGL game I played on both Linux and Windows seemed to be fine, please see

http://www.anandtech.com/print/1509

I realize it is dated (2004), but this was the last "big" game that I remember playing on Linux (maybe Quake 4, but it should be the same engine). The link shows that Windows version is consistently faster, sometimes almost 2x, than the Linux one. It would be surprising to find that performance has dropped so far as to be qualified as 'abysmal'.

Do you have some data to show that performance on Windows is so bad?


Reading up on this matter, it appears that I have misunderstood. Microsoft produced at one time some previews of Vista that had abysmal OpenGL performance.

http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-and-not-D...
In 2003, Microsoft left the OpenGL Architecture Review Board -- showing that they no longer had any interest in the future of OpenGL. Then in 2005, they gave presentations at SIGGRAPH (special interest group for graphics) and WinHEC (Windows Hardware Engineering Conference) giving the impression that Windows Vista would remove support for OpenGL except to maintain back-compatibility with XP applications. This version of OpenGL would be layered on top of DirectX as shown here, (from the HEC presentation) causing a dramatic performance hit. This campaign led to panic in the OpenGL community, leading many professional graphics programmers to switch to DirectX.


This was a hot, hot topic at the time.

However, Microsoft apparently backed down:
When Vista was released, it backpedaled on its OpenGL claims, allowing vendors to create fast installable client drivers (ICDs) that restore native OpenGL support. The OpenGL board sent out newsletters proving that OpenGL is still a first-class citizen, and that OpenGL performance on Vista was still at least as fast as Direct3D. Unfortunately for OpenGL, the damage had already been done -- public confidence in OpenGL was badly shaken.


Anyway, if Microsoft wanted so badly for everyone to believe that OpenGL performance on Vista, and subsequent Windows versions, would be abysmal, why should I not have believed them?

Indeed, the OpenGL performance provided by Microsoft for Vista was abysmal, and only action by hardware providers to create fast installable client drivers (ICDs) that restored native OpenGL support fixed the issue.

Who am I to spread a message contrary to what Microsoft marketing wanted to spread about OpenGL on Windows?

Edited 2010-09-22 13:57 UTC

Reply Score: 2

Drumhellar Member since:
2005-07-12

Direct3D and hardware mirror each other. They are developed in tandem. Direct3D is tailored to the hardware at the same time the hardware is tailored to Direct3D. There is give and take with all parties during development of the next version of the spec. This is how it used to be with OpenGL, before the ARB became so broken and OpenGL fell so far behind that it could only play catch-up with Direct3D.

Reply Score: 2

Drumhellar Member since:
2005-07-12

*facepalms*

Okay, so, hardware vendors don't control the spec. Hardware and Direct3D are developed in tandem.

Microsoft listens to software developers when they request feature X, and listens to hardware developers when they suggest that feature Y is feasible and useful. While Microsoft has the final say, it means nothing without participation from software developers hand hardware developers.

The reason why hardware vendors don't develop a spec in a vacuum, without feedback from software developers, is because the hardware vendors want to court software developers to target their hardware, thus increasing sales. Real innovation in graphics is a product of collaboration between all parties involved.

When a hardware vendor doesn't pay attention to what software vendors really want, you get something like this:
http://en.wikipedia.org/wiki/Voodoo_5

Developers weren't clamoring for motion-blur or even anti-aliasing yet. They wanted more than just a high fillrate. NVidia listened to what they wanted, and delivered Hardware transform & lighting, plus good 32-bit performance. ATI followed suit.

I won't attempt to address your comments on added complexity, as I originally took them to be a suggestion of Microsoft adding artificial complexity just to make the lives of Linux D3D developers more difficult. Now, I've got no idea what you're getting at.

And as for how Direct3D on Linux encouraging Windows development, well, OS/2 ran Windows 3.1 programs pretty well. As a result, instead of making OS/2 native apps, developers targeted the Windows API. As the Windows API evolved away from what OS/2 could run, developers moved with it.

Plus, if Linux-only developers start targeting Direct3D, they may start thinking, "well, hell, I can probably get my code to run on Windows pretty easily now."

Of course, it also applies the opposite way, and everybody benefits.

Reply Score: 2

lemur2 Member since:
2007-02-17

"The software in question is a "thin layer over the Gallium 3D driver layer". In turn, the Gallium3D driver is a part of the Linux kernel (which includes hardware drivers either directly or as kernel loadable modules). None of this is in any way a copy of any Microsoft software. There is no "copy and paste" here, this is a new implementation of the Direct3D API. Therefore, no copyright infringement can occur.

Can't microsoft patent some mechanism used in Direct3D, like e.g. tesselation ? Is it really only implementation that can be patented ?
"

You did not previously mention any patents.

Your quote: "..because actually implementing a full up-to-date D3D layer which people can use would be nearly impossible, due to... -Copyright infrigement"

Methods are the subject of patents ... which is to say that one can be awarded a patent on a method of doing something or other. In order for another party to avoid your patent, they would need to come up with a different method of doing that same thing.

Note that this does not mean that they cannot do that thing, it means only that they may not use the same method to do that thing. E.g. One company might get a patent for a headache tablet using panadine ... but that would not prevent another company making a headache tablet where the active ingredient was ibuoprofen.

"MS won't break the API unless they wish to break games.

Indeed. Owning the proprietary spec, they can, however, make the API much more complex at each release, meaning that Linux players won't be able to play latest games for some time.
"

Neither will the games themselves be written for the latest more complex API release for some time.

Also, the objective of an API is to make it easier for programmers to interface to the hardware, in order to unleash the power of the hardware for people to enjoy.

Surely you aren't suggesting that Microsoft should write deliberately obscured APIs for the sole purpose of making it harder for competition, rather than making it better for their customers?

I'm shocked, truly shocked! ;)

Or they can link it with windows-specific technology like .net as much as possible. Kinda the same problem as reimplementing the Flash spec.


Scandal! Surely you cannot believe Microsoft would be so evil?

"requiring the Gallium3D people to start over"

How so?

Sorry, I meant the part of the G3D project which works on reimplementation of D3D [/q]

You mean this state tracker. Meh. Direct3D is just an API. It isn't that hard to pass parameters between a calling program and the graphics hardware. If Microsoft made it wildly complicated, why would developers want to use the next DirectX 12? Why wouldn't they just stick with DirectX 11?

Reply Score: 2

lemur2 Member since:
2007-02-17

"The software in question is a "thin layer over the Gallium 3D driver layer". In turn, the Gallium3D driver is a part of the Linux kernel (which includes hardware drivers either directly or as kernel loadable modules). None of this is in any way a copy of any Microsoft software. There is no "copy and paste" here, this is a new implementation of the Direct3D API. Therefore, no copyright infringement can occur.

Can't microsoft patent some mechanism used in Direct3D, like e.g. tesselation ? Is it really only implementation that can be patented ?
"

BTW: Direct3D is only an API. Tessellation would be done in the hardware.

Now when I build my Linux machine, generally I put it together from parts ... I buy a blank hard disk, a motherboard, CPU & case, optical drive, keyboard, screen, mouse, RAM and graphics card. I assemble it all together, I put a Linux liveCD into the optical drive, and away I go, ready to run in about 20 minutes after that.

I can generally get the functional equivalent of a Windows 7 machine up and running this way for about a third of the cost of a store-bought Windows 7 machine of similar specifications.

The point is this: note that I purchased the graphics card. I therefore already have a license to use the graphics card.

http://en.wikipedia.org/wiki/Implied_license
Implied licenses often arise where the licensee has purchased a physical embodiment of some intellectual property belonging to the licensor


Therefore, because I have an implied license to use any Intellectual Property embodied within my legally-purchased graphics card, I may now use any tessellation features embedded within my graphics card.

I may even invoke such features of my graphics card via a Gallium3D state tracker software implementing the Direct3D API, if it so pleases me.

Edited 2010-09-22 10:16 UTC

Reply Score: 2

MORB Member since:
2005-07-06

Wine doesn't recompile everything. In a nutshell it loads x86 binaries in the PE format into a linux process and provide them with a reimplementation of the windows API.

There are other reasons why things are slow. Direct3D is reimplemented by wine on top of opengl but there are various data format differences between the two APIs that require time-consuming buffer conversions using the CPU. Additionally, shaders have to be recompiled as opengl shaders.

This causes a lot of complexity and overhead that an implementation of direct3d on top of gallium don't have to deal with.

Reply Score: 4

Neolander Member since:
2010-03-08

Wine doesn't recompile everything. In a nutshell it loads x86 binaries in the PE format into a linux process and provide them with a reimplementation of the windows API.

I don't think that they can simply do that. At the assembly language level, if say windows use INT1 for something and linux uses it for something else, running Windows programs without some kind of recompilation (I think the proper term is binary translation) would require changing the behavior of INT1, something which non-privileged software like Wine clearly can't do.

Same for loading PE, I don't think that Wine can do that on its own if the Linux kernel does not help. It probably has to create an ELF copy of the program at some point.

AFAIK, that's why the startup performance of Wine software is so poor by the way. Wine does not cache the translated program, it re-does the translation at each time.

There are other reasons why things are slow. Direct3D is reimplemented by wine on top of opengl but there are various data format differences between the two APIs that require time-consuming buffer conversions using the CPU. Additionally, shaders have to be recompiled as opengl shaders.

This causes a lot of complexity and overhead that an implementation of direct3d on top of gallium don't have to deal with.

I have some difficulties understanding how that can possibly work. How does thing work at the hardware level ? How are D3D and OpenGL normally interfaced with the hardware ?

Reply Score: 2

WereCatf Member since:
2006-02-15

Same for loading PE, I don't think that Wine can do that on its own if the Linux kernel does not help. It probably has to create an ELF copy of the program at some point.

Why would WINE need some special privileges to load up a file? Just the fact that it happens to be executable code doesn't change the fact any way that it's a file; it can be read to memory. WINE just parses the PE header, sets up the memory accordingly, and reads the contents of the file there. There is nothing special about it.

AFAIK, that's why the startup performance of Wine software is so poor by the way. Wine does not cache the translated program, it re-does the translation at each time.

Nope. WINE does not translate the code in any way.

Reply Score: 4

Neolander Member since:
2010-03-08

Why would WINE need some special privileges to load up a file? Just the fact that it happens to be executable code doesn't change the fact any way that it's a file; it can be read to memory. WINE just parses the PE header, sets up the memory accordingly, and reads the contents of the file there. There is nothing special about it.

Well, I see an issue about application software loading other programs all by themselves, it's memory protection. How can things like DEP/NX be enforced if software is not loaded by the operating system ?

Reply Score: 2

WereCatf Member since:
2006-02-15

Well, I see an issue about application software loading other programs all by themselves, it's memory protection. How can things like DEP/NX be enforced if software is not loaded by the operating system ?

Indeed, WINE does not work unless you give it permission to bypass DEP/NX. By default Linux doesn't enforce such but f.ex. in Fedora you specifically need to allow WINE to execute code in random memory locations.

Reply Score: 2

MORB Member since:
2005-07-06

I'm pretty sure neither windows or linux programs directly use int to do any system call directly. There's always a library or dll of some sort sitting between the application and the kernel, which is what wine reimplements.

As for loading a PE executable the only help needed from the kernel is the ability to mess around with the layout of the process address space, mark pages as executable etc. and there's an api for that.

Reply Score: 2

Neolander Member since:
2010-03-08

I'm pretty sure neither windows or linux programs directly use int to do any system call directly. There's always a library or dll of some sort sitting between the application and the kernel, which is what wine reimplements.

Yeah, I checked my reasoning and found out where I was wrong. INTs are only required for on-demand library loading, if it's written in the PE headers that the program requires x library to be loaded, no INT is required in the program itself...

Then I'm puzzled, why in hell is Wine's startup so slow ? Thought that I finally found out u___u

As for loading a PE executable the only help needed from the kernel is the ability to mess around with the layout of the process address space, mark pages as executable etc. and there's an api for that.

Okay so user-mode apps are provided with an API to manage memory protection themselves ? I'm not comfortable with such a design decision, but it indeed makes things simpler for Wine.

Edited 2010-09-22 10:16 UTC

Reply Score: 2

ba1l Member since:
2007-09-08

Then I'm puzzled, why in hell is Wine's startup so slow ? Thought that I finally found out u___u


When you load an application using Wine, you have to also load Wine itself. All those .dll files (or .so files - whatever) that Wine provides aren't being used by any Linux app, so they have to be pulled off the disk the first time they're used. It also needs to start some background processes to handle IPC between Windows programs.

Think of it this way - you have to boot up a copy of Windows before you can run any Windows applications.

Okay so user-mode apps are provided with an API to manage memory protection themselves ? I'm not comfortable with such a design decision, but it indeed makes things simpler for Wine.


Processes have (nearly) complete control over their own address space in Linux. That's how the dynamic linker (which isn't part of the kernel - it's part of glibc) works. You can map the contents of a file to any address you want, as long as it's not already in use.

It has no effect on other processes, and can not be used to bypass memory protection. The worst a process can do is crash itself.

Reply Score: 4

Neolander Member since:
2010-03-08

When you load an application using Wine, you have to also load Wine itself. All those .dll files (or .so files - whatever) that Wine provides aren't being used by any Linux app, so they have to be pulled off the disk the first time they're used. It also needs to start some background processes to handle IPC between Windows programs.

Think of it this way - you have to boot up a copy of Windows before you can run any Windows applications.

Thanks, this is a good explanation.

Processes have (nearly) complete control over their own address space in Linux. That's how the dynamic linker (which isn't part of the kernel - it's part of glibc) works. You can map the contents of a file to any address you want, as long as it's not already in use.

It has no effect on other processes, and can not be used to bypass memory protection. The worst a process can do is crash itself.

Consider DEP/NX. As a general rule, memory regions should not be writable and executable at the same time by normal user processes, as that possibility is often exploited by malware and almost never used by normal software. However, loading a PE executable without some help from the kernel requires exactly that, as WereCarf pointed out.

Edited 2010-09-22 20:03 UTC

Reply Score: 2

bert64 Member since:
2007-04-23

One of the reasons for wine having a slow startup speed is that, on a real windows system many of the core libraries would already be loaded and initialized during bootup because other system components require them, whereas under wine everything needs to be loaded.

And ofcourse userland programs have the ability to manage memory protection to some degree, the program itself has a better idea of its own memory layout than the kernel does.

Reply Score: 2

kaiwai Member since:
2005-07-06

...because actually implementing a full up-to-date D3D layer which people can use would be nearly impossible, due to...
-Copyright infrigement
-MS's ability to break the API every year, requiring the Gallium3D people to start over
-Speed (Wine recompiles programs first, but if I understand well this is about real-time translation, aka the main reason why old interpreters deeply suck)


Patents and copyright are two totally different beasts; how on earth can they copy code when Microsoft has never made the source code open to the world? now for patents you may be correct but many of these patents are so generic OpenGL are also impacted on them as well - so what ever implement on OpenGL will also cross over to the DirectX world in terms of patents. IIRC, Microsoft own several OpenGL patents that they bought off SGI many years ago.

Reply Score: 3

Soulbender Member since:
2005-08-18

-Copyright infrigement


API's can not be copyrighted or patented, afaik.

-MS's ability to break the API every year, requiring the Gallium3D people to start over


MS does not beak DirectX/D3D API's every year. if they did I wouldnt be able to run old DX7 games and older in DX9. Heck, if they did I couldnt even run yesteryears games this year. This is obviously not the case.

Reply Score: 2

lemur2 Member since:
2007-02-17

API's can not be copyrighted or patented, afaik.


AFAIK, copyright law comes into play when a later work includes major elements of an earlier copyrighted work.

http://en.wikipedia.org/wiki/Derivative_work
A derivative work pertaining to copyright law, is an expressive creation that includes major, copyright-protected elements of an original, previously created first work.


So, in order for an implementation of Direct3D on another non-Windows platform to be in trouble with regard to copyright law, the authors of the new non-Windows Direct3D implementation would need to have copied (stolen) a major chunk of Microsoft's copyrighted source code for Direct3D on Windows and pasted it verbatim into the new work.

So, as to the question of a Direct3D state_tracker for Gallium3D on Linux being a copyright violation in some obscure manner? Not a chance in hell.

Edited 2010-09-22 13:37 UTC

Reply Score: 2

Darkmage Member since:
2006-10-20

wine does NOT recompile programs. Wine is more like a png viewer for windows executables. It opens them and executes their contents. Nothing more, nothing less. It does not emulate anything. It simply takes windows calls and delivers them to linux. Then back to the program. There is no startup recompile when you run a windows app in wine.

Reply Score: 3

lemur2 Member since:
2007-02-17

wine does NOT recompile programs. Wine is more like a png viewer for windows executables. It opens them and executes their contents. Nothing more, nothing less. It does not emulate anything. It simply takes windows calls and delivers them to linux. Then back to the program. There is no startup recompile when you run a windows app in wine.


Indeed. However, Wine does provide the equivalent of Windows system dlls. To run a Windows binary under Wine, Wine must first load itself with its dlls (via elf), and then load the Windows binary code into RAM (via Wines .exe loader). Wine then adds the entry for the program's start point into the Linux kernel's scheduler, to start execution of the program.

When the Windows program makes a system call, Wine intercepts the call and does one of two things ... Wine either directs the call towards one of Wine's dlls, or Wine translates the paramaters of the call into a Linux system call. In either case, once the system call has completed, Wine translates the results into whatever format is the expected return values (in Windows) for that system call, and then returns back to running the Windows executable binary.

Even though as you say Wine does not recompile any binaries, nevertheless Wine does have extra overhead that is not required for that same binary executable running under Windows on the same hardware. The heaviest extra overhead is during startup of programs (i.e. loading the programs plus Wine itself into RAM).

PS: Note that DirectX emulation on Wine would currently probably be provided via a Wine dll. This new Gallium3D state tracker for DirectX API would probably allow Wine to use a "translated call to a Linux system call" method instead of a Wine dll.

Edited 2010-09-23 03:07 UTC

Reply Score: 3

Called it!
by intangible on Wed 22nd Sep 2010 21:07 UTC
intangible
Member since:
2005-07-06

Called this back when they announced DX10 and MS had recently talked about not allowing new versions of DirectX on XP: http://www.osnews.com/permalink?153301

Interesting all the down-vote hate I got at the time... especially since "disagreeing" with a statement wasn't supposed to be justification for down-votes on OSNews

Reply Score: 2