Intel Expresses Interest In AMD's Mantle API

[Nille]

IMHO they could add GLSL support too.

And then you has to rewrite all Shaders for each platform. And you get the one of the problems with Mantle too. Each vendor build his own Shader Compiler and each one produce different code.

If they what to fix that issue, i would prefer a FOSS-HLSL Shader Compiler.

[chithanh]

OpenGL is not currently consistent, but AMD can work on improving their drivers and making them consistent instead of fragmenting their attention between OpenGL and Mantle.

Do you assume that it is AMD's fault that OpenGL is inconsistent across vendors? What can AMD do to make OpenGL consistent between Intel and NVidia?

If the current generation is capable of mantle, the i don't see a reason why not someone implement for the Intel mesa driver.

Maybe the same reason why nobody implements OpenGL 3.0 in Intel GMA HD/Ironlake: http://www.phoronix.com/scan.php?pag...tem&px=MTMxMDQ
Someone has to do the work, and if there is no commercial interest in the hardware any more, that someone not going to be Intel. And if the task is too complex, then it won't be done by volunteers either.

[zeealpal]

Isn't Mantle based on HLSL?
This could be yet another 'trojan horse' inside Linux, as HLSL is controlled by Microsoft.

Sure, but why would AMD alter Mantle to every change MS does to HLSL? Didn't they base it off HLSL partly to make it easier to develop for?

[profoundWHALE]

INCOMING WALL OF TEXT

So here's the ways I can see this going as far as Mantle on Linux is concerned:
1) Port Mantle
- problems here with Catalyst (especially if they make them ~90% open source) and Open Source drivers
- if done through extensions there can be compatibility or dependency issues (I think?)
+ it's faster to implement

2) Write a Linux specific Mantle API along with their Catalyst replacement (the talked about mostly open source replacement)
+ less driver issues and guaranteed compatibility (which leads to)
+ better performance
- it'll take a while before we even get an alpha or beta version of either of these, possibly by the time Directx 12 comes out

3) Include Mantle API as part of an OpenGL 5 spec
+ Makes life easier for porters from Windows
- Does not fix the fragmentation issue
~ AMD/NVidia/Intel will be pressured to either support Mantle or drop OpenGL 5 altogether. If they drop support, it would effectively fragment OpenGL even more because you can bet that people would come up with an OpenGL 5 without Mantle.
~ If they do include support, then OpenGL 5 would take center stage and a lot of ARM manufacturers would likely jump on board.
- Would come out basically by the time Directx 12 would

| Or my favourite |

Rewrite OpenGL5 - Include checks for compatibility with things like Mantle, and then either asks the user to select Mantle or OpenGL, or automatically choses what should be fastest. (basically OpenGL 5 will have a legacy code 'converter', but will check for the hardware compatibility and if it is less than OpenGL 5, it will automatically 'convert' OpenGL 5 code to whatever legacy code it uses). It will also do the reverse for legacy code so that AMD/NVidia/Intel only need to worry about supporting OpenGL 5.
Replace Catalyst with that mostly open source and little bit proprietary one they're talking about. Without having to keep all the legacy stuff.

This is the only way OpenGL can save itself. If OpenGL 5 is the one that decides how to deal with legacy code, there would be no more fragmentation. Because it can deal with legacy code, people writing game engines or games in general don't have to worry about being compatible with older hardware. And again, it means that AMD/NVidia/Intel don't have to worry about being compatible with older versions of OpenGL.

Problem: When playing a game with legacy code (either new hardware playing an old game, or older powerful hardware playing a new game) there's bound to be something breaking or just general weirdness. All they have to do is keep it playable.

Solution: The open source community updating a database of exceptions that are specific to certain hardware/games to get around it.

And if this was all being worked on now, it'll probably be done about the same time as Dx12. A release candidate that only contains the OpenGL 5 spec and Mantle API compatibility (and whatever other APIs) could be out before then.

TL;DR OpenGL 5 needs to be rewritten from scratch, but to be successful it also needs to somehow be fast, compatible in some way with legacy code, all while keeping down or eliminating fragmentation.

So, tell me what you guys think and correct me if I confused some term or something like that.

[tuubi]

INCOMING WALL OF TEXT

No kidding...

So, tell me what you guys think and correct me if I confused some term or something like that.

Mostly you seem confused about the whole concept of an API. These "ways" of yours do not make any actual sense.

I'm not trying to be a dick here, so no reason to take offense.

[sarmad]

Mostly you seem confused about the whole concept of an API. These "ways" of yours do not make any actual sense.

I'm not trying to be a dick here, so no reason to take offense.

Actually, some of his suggestion make sense, i.e. the part about creating a "converter" of GL4 APIs into GL5. In other words, if they restart from scratch in GL5 with a simple and clean lower level API and write a single user mode implementation of GL4 using GL5 then that should solve the problem. This way manufacturers will only need to worry about supporting the simpler GL5 without worrying about backward compatibility as they will get that for free. Basically, it's the same as the DX-GL wrapper that some developers use for porting. Obviously, hardware that is not GL5 compatible will just have to provide its own GL4 implementation the same old way.

[profoundWHALE]

Actually, some of his suggestion make sense, i.e. the part about creating a "converter" of GL4 APIs into GL5. In other words, if they restart from scratch in GL5 with a simple and clean lower level API and write a single user mode implementation of GL4 using GL5 then that should solve the problem. This way manufacturers will only need to worry about supporting the simpler GL5 without worrying about backward compatibility as they will get that for free. Basically, it's the same as the DX-GL wrapper that some developers use for porting. Obviously, hardware that is not GL5 compatible will just have to provide its own GL4 implementation the same old way.

This^ I was thinking of something like this.

P.S. I know I have very little knowledge of what I'm talking about, but I have an idea of how things work... kind of? I just wanted to know if any of those ideas are sort of possible.

I don't want to see Dx12 win and leave OpenGL in the dust, so I've been racking my brain trying to think of something and this is the best I could come up with.

[tuubi]

I don't want to see Dx12 win and leave OpenGL in the dust, so I've been racking my brain trying to think of something and this is the best I could come up with.

No fear of that as long as D3D is only available on MS platforms. Unless by winning you mean simply monopolising the pc gaming sector, which D3D has already done. Never quite killed off OpenGL though, for obvious reasons.

If Linux as a gaming platform fails to survive (which I doubt), OpenGL and its shortcomings won't be to blame. In any case, we can probably expect lots of positive changes from the next iteration of the API with all this feedback flowing in from the game industry lately. I doubt it'll materialise any time soon though due to the way Khronos works. Where's a benevolent dictator when you need one?

[0xBADCODE]

Commited to DOUBLE standards?

open standards like Microsoft's DirectX API

I would rather call this phrase as commitment to DOUBLE standards. DX? Open? Ha-ha-ha, what a double-standards speech. They should also try to rename black into white.

[log0]

I would rather call this phrase as commitment to DOUBLE standards. DX? Open? Ha-ha-ha, what a double-standards speech. They should also try to rename black into white.

With open he meant open to them (IHVs) and not to you and me, as they usually work together with MS on each new DX API version.