Valve begins publicly listing AMD catalyst driver bugs in Linux

[LAwLz]

AAMD talks big on being open source but actually they aren't much better than Nvidia, just ask LAwLz for more on that

Well credit where credit's due. If they gave Khronos full and unrestricted access to Mantle then they are quite a bit better than Nvidia. It's not really anything to brag about being better than "terrible" though.

[mr moose]

Forgive me, but you clearly don't get it. Big media/game servers use GPU's to compress/decompress lots and lots of data on its way in and out of a system. In the corporate world, where SQL is ubiquitous, exactly how do you think the back-end implementations of the search algorithms are implemented? If you're not GPU-accelerated at this point, you're not competitive.

Forgive me that you didn't read my post, how many game servers did I mention and how many of those SQL servers use consumer GPUs?  None, they are mostly files servers and domain controllers.

[patrickjp93]

Forgive me that you didn't read my post, how many game servers did I mention and how many of those SQL servers use consumer GPUs? None, they are mostly files servers and domain controllers.

You do know the only difference between Firepro and Radeon is binning and ECC memory, right? AMD would be stupid to not develop Linux drivers for its cards.

[Notional]

You do know the only difference between Firepro and Radeon is binning and ECC memory, right? AMD would be stupid to not develop Linux drivers for its cards.

You do know the difference between radeon and firepro drivers right? You can get firepro drivers for Linux x86 and linux x86_64 http://support.amd.com/en-us/download/workstation/certified

Why would anyone need radeon drivers for linux on a server?

[patrickjp93]

You do know the difference between radeon and firepro drivers right? You can get firepro drivers for Linux x86 and linux x86_64 http://support.amd.com/en-us/download/workstation/certified

Why would anyone need radeon drivers for linux on a server?

Do you know what the difference in drivers is? It ain't much other than how the dispersion is handled (memory allocation across much more VRAM down at the boiler plate level). Could you people for one look beyond layer 1 of a given situation? How did any of you graduate high school?

[Notional]

Do you know what the difference in drivers is? It ain't much other than how the dispersion is handled (memory allocation across much more VRAM down at the boiler plate level). Could you people for one look beyond layer 1 of a given situation? How did any of you graduate high school?

The point is garuentee from AMD, that their Firepro cards works with certain software on certain OS platforms. The critique from Valve here, is that gaming and multimedia things (sound over hdmi?) does not work properly for a consumer. That has little to nothing to do with compute functions on a server, from a driver perspective. Your ad hominem does not strengthen your argumentation, insulting peoples educational level.

 

Ain't much other than memory handling? Ah so those gaming drivers, that improves fps by x% is only memory handling? Come on. Full support of certain pro software in server farms, is not much more than memory allocation? You know that is not true.

[patrickjp93]

The point is garuentee from AMD, that their Firepro cards works with certain software on certain OS platforms. The critique from Valve here, is that gaming and multimedia things (sound over hdmi?) does not work properly for a consumer. That has little to nothing to do with compute functions on a server, from a driver perspective. Your ad hominem does not strengthen your argumentation, insulting peoples educational level.

 

Ain't much other than memory handling? Ah so those gaming drivers, that improves fps by x% is only memory handling? Come on. Full support of certain pro software in server farms, is not much more than memory allocation? You know that is not true.

Yeah, it all comes down to memory handling actually. Did you know you can optimize performance on a memory-intensive application by always making your arrays the length of a page-slice since that's all that can be imported at a time from your rotating rust or ssd? It's similar to a just-in-time compiler which optimizes where things should go for rapid access and transformation. 1 cycle shaved per task * a lot of tasks = a lot of cycles = performance boost. Optimal arrangement of the data can save loads of processor time. 

 

The other thing is direct translation of data types, which, honestly, AMD sucks at. There's a certain way each OS kernel wants info packaged, and the driver does need to know how to translate from one side to the other, but other than that it all boils down to how well data is managed in memory to be able to consolidate resources and instructions. That's the key purpose of a driver.

[Ren]

Well, OpenGL just sucks, so...

Don't see how you can side with anyone on that topic. Anyway, I don't see attempts at embarassment doing anything. Clueless as to what they're actually trying to do.

[Notional]

Yeah, it all comes down to memory handling actually. Did you know you can optimize performance on a memory-intensive application by always making your arrays the length of a page-slice since that's all that can be imported at a time from your rotating rust or ssd? It's similar to a just-in-time compiler which optimizes where things should go for rapid access and transformation. 1 cycle shaved per task * a lot of tasks = a lot of cycles = performance boost. Optimal arrangement of the data can save loads of processor time. 

 

The other thing is direct translation of data types, which, honestly, AMD sucks at. There's a certain way each OS kernel wants info packaged, and the driver does need to know how to translate from one side to the other, but other than that it all boils down to how well data is managed in memory to be able to consolidate resources and instructions. That's the key purpose of a driver.

Thanks for a nice post. But in gaming, I thought the driver optimizations where more than just that. But instructions what not to draw (out of fov), ways to reuse redundant processing, etc. I don't know much about drivers, but just memory allocations, just sounds like too little

[patrickjp93]

Thanks for a nice post. But in gaming, I thought the driver optimizations where more than just that. But instructions what not to draw (out of fov), ways to reuse redundant processing, etc. I don't know much about drivers, but just memory allocations, just sounds like too little

What not to draw should be implemented in the engine in itself, not the driver. Good lord hard-wired occlusion culling...That'd be beastly.

[Notional]

What not to draw should be implemented in the engine in itself, not the driver. Good lord hard-wired occlusion culling...That'd be beastly.

Oh yeah I completely agree. But you do see AMD and Nvidia drivers bringing performance increase to specific titles. That must be more than just memory allocation. Anyways, when it comes to servers and firepro, I don't know all that much. But my link does show drivers specifically for pieces of software and OS'; so it should properly support Linux, when it's a firepro driver for Linux.

[Rhys R]

*snip* cannot be bothered continuing a pointless fight.

[osbios]

Linux only holds a measly 1.67% percent of the desktop market share. How often are you really going to see a server running a GPU? UNIX-Like operating systems don't even hold 90% of the server market either; the estimated amount of windows servers was about 32%.

 

There are no real numbers about Linux Desktop simply because it is free. The best numbers so far are the steam surveys. But they are only showing how many people use Ubuntu/Debian (Or what else is compatible) and install Steam on it and then continue to use it.

 

 

Yeah, it all comes down to memory handling actually. Did you know you can optimize performance on a memory-intensive application by always making your arrays the length of a page-slice since that's all that can be imported at a time from your rotating rust or ssd? It's similar to a just-in-time compiler which optimizes where things should go for rapid access and transformation. 1 cycle shaved per task * a lot of tasks = a lot of cycles = performance boost. Optimal arrangement of the data can save loads of processor time. 

 

The other thing is direct translation of data types, which, honestly, AMD sucks at. There's a certain way each OS kernel wants info packaged, and the driver does need to know how to translate from one side to the other, but other than that it all boils down to how well data is managed in memory to be able to consolidate resources and instructions. That's the key purpose of a driver.

 

page-slice? direct translation of data types? Sorry, but you don't make much sense to me.

You read/write data from HDDs or SSDs in big chunks. Or in case of SSDs also big lists of smaller chunks (aka 64 thread).

And SSDs have very high latency if you compare them to system memory. For applications it still is just: "OS please read this data range from file X, copy them to memory address Y and poke me when you are done. I do other stuff now."

 

The biggest difference in GPU memory handling is where buffers are placed.

System ram = fast random access by the CPU but if GPU uses it, the bus (e.g. PCIe) or the System Memory will be the speed limit.

Vram = CPU access is limited by bus speed and uncached (For performance you only want to read or write sequential), but for the GPU its full read/write speed.

 

 

 

What not to draw should be implemented in the engine in itself, not the driver. Good lord hard-wired occlusion culling...That'd be beastly.

Tilled rendering is basically doing that on the level of the Fragment Shader. (Also a long time ago there where certain "optimizations" for 3d benchmarks in nvidia and ati drivers if I remember correctly. )

 

There are a lot of hardware optimizations that you do no have direct control over. At last not with the current APIs(OpenGL/Direct3D). You just try NOT to create cases in which the driver may have to disable them.

For example early Z rejection and Hierarchical Z. You want this features? Don't manually write depth values in the Fragment Shader! There are size limits for the render target, too!

Also you have to use clear on the render target or tilled rendering, Hierarchical Z, MSAA, etc... will degrade in performance. Meaning: there are a lot of performance related things that are not specified by the APIs!

 

 

I guess most driver optimization is fixing stupid things applications do (for example not clearing a render target) and bake really well optimized versions of there shaders.

[patrickjp93]

Oh yeah I completely agree. But you do see AMD and Nvidia drivers bringing performance increase to specific titles. That must be more than just memory allocation. Anyways, when it comes to servers and firepro, I don't know all that much. But my link does show drivers specifically for pieces of software and OS'; so it should properly support Linux, when it's a firepro driver for Linux.

Okay, games are built on 3 languages (sometimes 4 if the debs were really good with CUDA) OpenGL, OpenCL, and the C/C++ for the CPU side. The GPU driver translates OpenGL and OpenCL into shader and GPU core instructions respectively. Sometimes there's a better way to do the tessellation or matrix algebra involved in a frame. Sometimes a poorly programmed batch of OpenCL can be translated to something more efficient but with the same result. Drivers can do that too, but a lot of it is finding the best way to arrange memory so there are no bank switches necessary between groups of instructions in memory blocks. Those are extremely expensive to processing time.

[patrickjp93]

There are no real numbers about Linux Desktop simply because it is free. The best numbers so far are the steam surveys. But they are only showing how many people use Ubuntu/Debian (Or what else is compatible) and install Steam on it and then continue to use it.

 

 

 

page-slice? direct translation of data types? Sorry, but you don't make much sense to me.

You read/write data from HDDs or SSDs in big chunks. Or in case of SSDs also big lists of smaller chunks (aka 64 thread).

And SSDs have very high latency if you compare them to system memory. For applications it still is just: "OS please read this data range from file X, copy them to memory address Y and poke me when you are done. I do other stuff now."

 

The biggest difference in GPU memory handling is where buffers are placed.

System ram = fast random access by the CPU but if GPU uses it, the bus (e.g. PCIe) or the System Memory will be the speed limit.

Vram = CPU access is limited by bus speed and uncached (For performance you only want to read or write sequential), but for the GPU its full read/write speed.

 

 

 

Tilled rendering is basically doing that on the level of the Fragment Shader. (Also a long time ago there where certain "optimizations" for 3d benchmarks in nvidia and ati drivers if I remember correctly. )

 

There are a lot of hardware optimizations that you do no have direct control over. At last not with the current APIs(OpenGL/Direct3D). You just try NOT to create cases in which the driver may have to disable them.

For example early Z rejection and Hierarchical Z. You want this features? Don't manually write depth values in the Fragment Shader! There are size limits for the render target, too!

Also you have to use clear on the render target or tilled rendering, Hierarchical Z, MSAA, etc... will degrade in performance. Meaning: there are a lot of performance related things that are not specified by the APIs!

 

 

I guess most driver optimization is fixing stupid things applications do (for example not clearing a render target) and bake really well optimized versions of there shaders.

There's an optimal amount of virtual memory one can read from a drive at a time from a virtual file called the page table. Tailoring arrays and strings to group and fit within I believe 884 bytes (it's called a slice, not 100% sure on the byte count though as it's been a long time since I built an optimal data structure) improves performance of an application with lots of file IO.

 

Yes I know SSD and HDD latency is huge. Duh.

 

What is called a buffer in the GPU world is really just a bank on RAM. Now, virtualizing its internal tables for quiz translation and minimizing memory misses, that's tricky and something drivers improve upon all the time.

 

I admit I'm not super familiar with advanced shader tools now so I won't comment on how or how not to intelligently program large-scale game shading, but internal drivers fix stupid code and intelligently allocate memory/virtual tables of RAM while also speaking the language of the OS's PCIe manager (data type translation).

[mr moose]

There are no real numbers about Linux Desktop simply because it is free. The best numbers so far are the steam surveys. But they are only showing how many people use Ubuntu/Debian (Or what else is compatible) and install Steam on it and then continue to use it.

 

 

 

Sorry but not at all, Gartner, IDC and netmarketshare all have very accurate data on OS market share as this research is a critical tool for many developers and manufacturers.   On the other hand Steam surveys are only good for determining what its gamers are using.

 

The margin of error for all of these researchers is well within tolerable limits.

[Silver]

Do you think this is kind of like YouTube posting which ISPs are making your internet bad? Like they're trying to kick AMD in the butt to get it working again? That's immediately what I thought of when I saw this news article.

[Humbug]

More problems...

Yet another AAA game was released on Linux; Civilization Beyond Earth.

 

This time AMD even had a partnership with the developer as part of the gaming evolved program. They even support Mantle on Windows.

And yet on Linux AMD's drivers continue to pose problems with the driver seeming to hit a wall at 30fps. The result of this is comical; an R9 290 performing like a 750ti.

 

 

The power consumption figures also show the R9 290 system taking very little power; pulling less than a 760.

Proving that the driver is not even asking the GPU to work hard.

 

 

Thanks to phoronix for the testing!

http://www.phoronix.com/scan.php?page=article&item=civ_beyondearth_linux&num=3

 

Bare in mind that this is a game which on Windows (using Mantle though) a Hawai card will even beat a GTX 980 by a big margin.

http://linustechtips.com/main/topic/238630-mantle-demonstrates-smoother-gameplay-in-civ-5-beyond-earth-what-it-means-for-the-industry/#entry3273473

[TAK]

.

[TheMidnightNarwhal]

Surprising considering Linux is a free to all thing, and AMD seems to be similar, I thought those two would be gay for each other (no offense meant to gays)

 

AMD is a female...

[Humbug]

I too find it odd that AMD is the one with closed drivers, seeing as they claim to be so open. What the point of keeping the drivers closed is

trade secrets. Neither AMD or nvidia want to open source their drivers because they are both hiding some performance tweaking techniques from each other and Intel. AMD does have their open source drivers separately But they will not open source catalyst.

[Altecice]

They should also post driver bugs in windows... believe me there are plenty. Either they decided not to fix them or they aren't skilled enough to do it.... im better the latter.

[Trik'Stari]

AMD is a female...

Um....what?

[patrickjp93]

Um....what?

I believe he means the mascot, which is a redheaded woman.

[Humbug]

They should also post driver bugs in windows... believe me there are plenty. Either they decided not to fix them or they aren't skilled enough to do it.... im better the latter.

on windows most people have a Good experience. Both nvidia and AMD do have bugs But in General it's a Good experience. Valve's strategy is to make sure that in the long term pc gaming is not reliant on windows. They are try to push devs and hardware vendors to make that happen. which is Why we see so many Linux game announcements these days.