Understanding More Of AMD's Open-Source HSA Plans

[Nobu]

Strictly speaking each programing language has its own programing modes and examples. C type languages for example have multidimensional tables, tale, if/else -type, as long is valid -type and goes on. 3D languages have some less and some more (textures for example). A language is not only the typos, so D3D-API + HLSL = D3D graphics language. The difference of low level APIs and high level like D3D and OGL is that with low level, graphics are distributed in low level shader model 3-4-5 assembly (no Representation, API, SL compiler, API calls, needed), only HW compiling needed. With high level APIs, AMD, MS, NV and Intel have created a paradox, the first programing language in the world that everything is distributed in shader language bytecode, unmodeled, lowered source code. Even OCL and Java don't do that. Why? AMD's share holders are criminals as the rest above, that enforce legally (with paid laws) and illegally a graphics monopoly. If you had a company Mr Bridgman, you would have code of another corporation's standard inside your driver or you would have only your own?

I don't know a whole lot about shaders, so excuse me if I'm wrong, but you don't have to distribute them that way. You could distribute them uncompiled, and allow the client to compile them, but that would be inefficient. Anyway, you aren't forced to use AMD's GPUs, or any other. Nor are you forced to play games. If you feel like throwing your money at a solution to the "Monopoly", maybe you should help fund those Open GPUs instead of running your mouth at someone who simply works at a company that you don't appear to like, who may even hold a similar opinion to yours?

[bridgman]

Strictly speaking each programing language has its own programing modes and examples. C type languages for example have multidimensional tables, tale, if/else -type, as long is valid -type and goes on. 3D languages have some less and some more (textures for example). A language is not only the typos, so D3D-API + HLSL = D3D graphics language.

OK so far...

The difference of low level APIs and high level like D3D and OGL is that with low level, graphics are distributed in low level shader model 3-4-5 assembly (no Representation, API, SL compiler, API calls, needed), only HW compiling needed. With high level APIs, AMD, MS, NV and Intel have created a paradox, the first programing language in the world that everything is distributed in shader language bytecode, unmodeled, lowered source code. Even OCL and Java don't do that. Why?

HLSL source can be compiled to HLSL bytecode but the API calls don't change, can't be compiled, and are still required.

Java is generally distributed as bytecode, similar to HLSL. OpenCL is picking up a comparable bytecode mechanism (SPIR, based on LLVM IR).

I don't believe OpenGL has a comparable "portable bytecode" mechanism, only compilation to HW ISA which is not generally suitable for distribution.

AMD's share holders are criminals as the rest above, that enforce legally (with paid laws) and illegally a graphics monopoly. If you had a company Mr Bridgman, you would have code of another corporation's standard inside your driver or you would have only your own?

Sorry, but I have no idea what you are talking about. Are you saying that we are criminals because we support GL and DX standards ? If not, what is the illegal graphics monopoly you are talking about ?

If I had a company making graphics products I would quite probably have SDK content (mostly header files) for another company's standard inside my driver since that would be a pre-requisite for supporting any common graphics standard. If you are asking "would I steal another company's code" the answer is no, if you are asking "would you use another company's code under the terms of its license" the answer is yes. Are you saying that somehow makes me a criminal ?

I don't know a whole lot about shaders, so excuse me if I'm wrong, but you don't have to distribute them that way. You could distribute them uncompiled, and allow the client to compile them, but that would be inefficient. Anyway, you aren't forced to use AMD's GPUs, or any other. Nor are you forced to play games. If you feel like throwing your money at a solution to the "Monopoly", maybe you should help fund those Open GPUs instead of running your mouth at someone who simply works at a company that you don't appear to like, who may even hold a similar opinion to yours?

GLSL shaders are generally distributed uncompiled, but I believe HLSL shaders are generally distributed "semi-compiled", ie converted to HW-independent bytecode. Both are compiled on the user's system, either each time the app starts up or once during the initial run then saved as HW-specific binary.

[artivision]

OK so far...



HLSL source can be compiled to HLSL bytecode but the API calls don't change, can't be compiled, and are still required.

Java is generally distributed as bytecode, similar to HLSL. OpenCL is picking up a comparable bytecode mechanism (SPIR, based on LLVM IR).

I don't believe OpenGL has a comparable "portable bytecode" mechanism, only compilation to HW ISA which is not generally suitable for distribution.



Sorry, but I have no idea what you are talking about. Are you saying that we are criminals because we support GL and DX standards ? If not, what is the illegal graphics monopoly you are talking about ?

If I had a company making graphics products I would quite probably have SDK content (mostly header files) for another company's standard inside my driver since that would be a pre-requisite for supporting any common graphics standard. If you are asking "would I steal another company's code" the answer is no, if you are asking "would you use another company's code under the terms of its license" the answer is yes. Are you saying that somehow makes me a criminal ?



GLSL shaders are generally distributed uncompiled, but I believe HLSL shaders are generally distributed "semi-compiled", ie converted to HW-independent bytecode. Both are compiled on the user's system, either each time the app starts up or once during the initial run then saved as HW-specific binary.

My meaning is very easy to understand: Tell MS that with D3D12 there will be no more state trackers and d3d libraries inside your driver. They can target themselves your IL with their shader compiler and a simple d3d_compiler IL backend, or they can have their own IL and target themselves you HW via your HW backend. Basically d3d shouldn't be driver related, as when you program for OpenCL. As AMD is in a mafia deal with MS to hold d3d driver related and OS forced, my opinion will not change.

[bridgman]

My meaning is very easy to understand: Tell MS that with D3D12 there will be no more state trackers and d3d libraries inside your driver. They can target themselves your IL with their shader compiler and a simple d3d_compiler IL backend, or they can have their own IL and target themselves you HW via your HW backend. Basically d3d shouldn't be driver related, as when you program for OpenCL. As AMD is in a mafia deal with MS to hold d3d driver related and OS forced, my opinion will not change.

I'm sorry, but what you're saying still doesn't make sense. You keep talking about just IL and ignoring the runtime API functions. Both are required.

You need a shader compiler for the IL and a driver for the runtime API.

[artivision]

I'm sorry, but what you're saying still doesn't make sense. You keep talking about just IL and ignoring the runtime API functions. Both are required.

You need a shader compiler for the IL and a driver for the runtime API.

------------------------------------------ and a low level driver for the specific shader model, not the API. Give them a unified connection for their APIs with your driver and drop libd3d32 and any kind of state tracker, offload this burden to them. Linux people that trust AMD today, they will be disappointed if D3D12 cannot run natively via Wine and Linux Catalyst again.

[bridgman]

------------------------------------------ and a low level driver for the specific shader model, not the API. Give them a unified connection for their APIs with your driver and drop libd3d32 and any kind of state tracker, offload this burden to them. Linux people that trust AMD today, they will be disappointed if D3D12 cannot run natively via Wine and Linux Catalyst again.

??? OK, so you're thinking that if we were able to force MS to write the D3D graphics driver they would magically license it for use on Linux ?

[artivision]

??? OK, so you're thinking that if we were able to force MS to write the D3D graphics driver they would magically license it for use on Linux ?

Mr Bridgman, first of all there is no disrespect for you or any other developer, we mainly have respect for you because you are here answering our questions. Second, 2 years from now, people with their open drivers, state trackers, instruction set efficient emulators and Linux, they will not have the immediate need for x86, arm, catalyst, windowz. And 4 years from now your consoles will go out for the same reason. So after some years AMD, Intel, NV and others, will have to answer to this community. You will be surprised when some words from acknowledged people around forums like this, can break apart even a company like AMD, this time will come. My thinking is to seriously listen to our opinions and speak to you bosses. I don't now if MS will license something or users will use it via Wine anyway. That i do now is that api specific driver isn't needed, apis are shader converters, they do not participate in graphics execution by GPU. But anyway forget that as all, linux gamers they want all the available games to be there for linux even non natively but surely efficiently, and they blame AMD and NV a lot for that, so somehow you have to compensate. There are many ways, but make no mistake this isn't asking.

[Nobu]

If a game isn't available for Linux, I generally won't buy it (ignoring console games, here, of course). I don't blame nvidia, amd, or intel for the lack of games, that would be short-sighted. It is the game developers who decided which platforms to support, and that had more to do with how much money they would make on those platforms than the available graphics API ever would...or else they would still be making games for PS1 (or Dreamcast...we can only hope! ).

As far as Wine is concerned, it's a horrible shim most of the time, and a work of art sometimes. When there are no graphical glitches (there are few, but they usually make the game unplayable), there are often other glitches (sound, control, etc.) and I would never want to need it. For that reason alone, I'm not the least bit excited about a D3D12 state-tracker (or any other similar work). Although I wouldn't mind having one, it's not something to lose your breakfast over, in my humble opinion.

[artivision]

If a game isn't available for Linux, I generally won't buy it (ignoring console games, here, of course). I don't blame nvidia, amd, or intel for the lack of games, that would be short-sighted. It is the game developers who decided which platforms to support, and that had more to do with how much money they would make on those platforms than the available graphics API ever would...or else they would still be making games for PS1 (or Dreamcast...we can only hope! ).

As far as Wine is concerned, it's a horrible shim most of the time, and a work of art sometimes. When there are no graphical glitches (there are few, but they usually make the game unplayable), there are often other glitches (sound, control, etc.) and I would never want to need it. For that reason alone, I'm not the least bit excited about a D3D12 state-tracker (or any other similar work). Although I wouldn't mind having one, it's not something to lose your breakfast over, in my humble opinion.

You seam to losing the point: A friend came by my house and ask me to install Linux on his PC plus to teach him some things. I accepted for free and then he asked me the difficult question - can i play this latest MMO with Linux? Even if gamers are just a 20%, that is enough to crumple Linux expansion. Except if you care only for your self (if you only have Linux then everything is ok).

[Nobu]

You still can't blame AMD for that, getting rid of d3d and/or ogl won't make publishers suddenly port their games to Linux, a state-tracker won't suddenly make wine the perfect gaming platform (It'd help, but there are other Windows APIs which need to be implemented...correctly, or else games will continue to break when run through wine).

If you absolutely must have the latest-greatest MMO, for now Windows is your best bet. That may change soon, with Valve promoting their Steam Machines, but not everyone is buying it (the idea) yet and publishers (EA, looking at you) are still targeting Windows as a primary platform. You could still install Linux in a VM with hardware accel., or install Windows in a VM the same way, or dual-boot (they each have their own benefits)...nothing wrong with that. But expecting AMD to control game publishers, or cater to gamers by writing a d3d state-tracker, is asking a lot. We are not their primary audience, and they don't make a lot of money from our purchases (if you consider the sheer number of servers out there, and how much the processors for those cost, the gaming market is minuscule in comparison...even including the Windows side).