amdgpu questions

[bridgman]

I have one more

What about "deprecated" FirePRO cards still being sold today, like the ones based on Tahiti? With fglrx being dropped and no SI support in amdgpu, those will eventually be "useless". Sure, they should work with radeon+mesa but that's not what anyone buys a FirePRO for. Will there be extended fglrx support for pro customers or will AMD just refer to LTS distributions?

Unless there was an announcement I missed they are not deprecated. Did you see something I didn't ?

I'm hoping we can move them all to amdgpu hybrid. If that doesn't work then we'll have to extend fglrx support, and we may have to do some of that anyways. Wherever possible, though, we would rather invest time in amdgpu than fglrx.

[juno]

Yeah you did prove before that you don't care about gaming and don't want to or can't put yourself in the position of gamers. No, you or your kid are not valid reference for the world's population. btw: using Windows for gaming is just being pragmatic but I don't even play games atm and have no active Windows installation if that does satisfy you or calm you down.
And this is far off topic.

[juno]

If you have a home cinema amplifier with hdmi inputs I undestand the need [...]

Yes I do have one. But thanks for the tip
I don't like the situation either. HDMI being the standard for audio transmission but it doesn't go without video signal... at least using Linux I can set the 2nd monitor (amp) to overlap the primary and not bother. On Windows it has to be next to the primary so I 'lose' the mouse sometimes. Connecting the monitor through the amp is not an option with WQHD and 144 Hz...

[juno]

I have one more

What about "deprecated" FirePRO cards still being sold today, like the ones based on Tahiti?
With fglrx being dropped and no SI support in amdgpu, those will eventually be "useless". Sure, they should work with radeon+mesa but that's not what anyone buys a FirePRO for. Will there be extended fglrx support for pro customers or will AMD just refer to LTS distributions?

[drSeehas]

... AFAIK the "canonical reference" for hardware is the Wikipedia pages, and they seem to be wrong in this case as well (describing some parts as being based on Cape Verde when I'm pretty sure they are actually Iceland/Topaz). ...

It would be nice if you would revise the Wikipedia pages.

[bridgman]

IIRC "dual graphics" in Windows is another name for "Hybrid Crossfire", ie splitting a single graphics workload across two GPUs where one is the integrated graphics in an APU. If so then no plan to support that in amdgpu however one of the goals of Vulkan/DX12 is to shift that functionality from driver to game engine or app.

The 6 CU / 384SP number sounds right but my recollection was that Topaz had a 64-bit memory bus, which would make the performance of the two parts relatively similar (one has bigger engine, one has bigger tires ). If you dig a bit deeper into the techpowerup database you'll see that the references to 128 bit memory (at least the ones I looked at) describe memory as "system shared" (presumably the dual channel DIMMs) which is AFAIK not correct; the 64-bit references correctly talk about separate VRAM on a 64-bit bus.

EDIT - looks like the 64/128-bit confusion comes from the way that some tools describe the "composite" GPU - picking up 128-bitness from the APU's DIMMs and VRAM-ness from the dGPU.

The driver code does have some provision to deal with unequal render times, basically separating rendering from presentation with a short flip queue in between.

AFAIK the "canonical reference" for hardware is the Wikipedia pages, and they seem to be wrong in this case as well (describing some parts as being based on Cape Verde when I'm pretty sure they are actually Iceland/Topaz). My CZ laptop has a Topaz in it AFAIK, will check that.

[juno]

Topaz/Iceland has been a mystery for me... from amdgpu source I got that it is a GPU w/o DCE, VCE and UCD. Looks to me like it was intended for dual-graphics in notebooks along with Carrizo-APUs.
So first question: is there even dual-graphics support in amdgpu? If not, you can ignore the rest of the post

The GPU database on techpowerup (which I know is not entirely correct) states 384 shader processors / 6 CUs for PRO as well as XT (http://www.techpowerup.com/gpudb/#topaz). Also it sais there should be a 128 bit wide GDDR5 and PCIe3.0x8 interfaces which seems legit to me.
In theory and in my unprofessional opinion, this combination seems very unbalanced. The 8 CU APU GPU having <34 GiB/s of memory bandwidth shared with the CPU part and the second GPU with only 6 CUs having 64 GiB/s. How do you balance that in real time 3D, where we rely on alternate frame rendering for multi-GPU configurations? Are there provisions made in the drivers to balance and smooth that out?

[bridgman]

so ROCK = amdkfd?
What is the advantage of using roc instead of OpenCL, the platform/vendor-independent solution with a dGPU?

Correct...

ROCK = Radeon Open Compute Kernel driver,
ROCT = ROC Thunk
ROCR = ROC Runtime
ROCM = ROC platforM (I had to ask about that one)

ROCM isn't an alternative to OpenCL itself, it's an alternative to what OpenCL runs over today. Actually OpenCL has picked up part of the stack already, in the sense that it compiles OpenCL kernels to HSAIL rather than AMDIL, but next step would be to run it over the ROC stack rather than over the graphics driver like we do today. We already do this for testing.

Think "optimized compute stack with a bunch of languages running over it". The design exercise started as "what would be the ideal low level stack for OpenCL 2.0 ?" then we generalized to support other languages equally well. OpenCL 2.0 is a fairly different beast from earlier versions, in the sense that earlier versions were limited to things that could run well over a typical graphics driver of the time.

[monraaf]

so ROCK = amdkfd?
What is the advantage of using roc instead of OpenCL, the platform/vendor-independent solution with a dGPU?

[bridgman]

Radeon Open Compute is the "branding" for our HSA stack. It runs a bit ahead of HSA standards - as we find things are needed we implement them and propose them to HSAF in parallel. It doesn't replace OpenCL, but it probably will replace the lower level code that OpenCL runs over today.

HCC is another language available alongside OpenCL, and is already open source.

HIP is a porting tool that helps to convert CUDA to portable C++ which can run over HCC or NVCC (and maybe over Intel's new stack as well, not sure). Basically it's about C++ parallel extensions evolving far enough to be a good portable standard for GPU compute, and helping people move their existing programs to it.

The HSA/ROC stack is now running on dGPUs as well, initially focusing on Fiji.