Radeon Pro Vega II Duo (look at this monster)

[M344587487]

https://www.amd.com/en/graphics/work...on-pro-vega-ii


https://old.reddit.com/r/Amd/comment...card_infinity/


https://old.reddit.com/r/Amd/comment...rt_of_new_mac/

• Two MI60 chips on the same board with an 84GB/s infinity fabric link connecting them
• 128 CU's
  
• "Up to 64GB HBM2" meaning 2x16GB or 2x32GB

Each chip should have slightly more throughput than a Radeon VII when doing disjoint tasks due to the extra CU's. There is an outside chance that a single test could span both chips (not efficient, maybe not too detrimental to throughput in theory not that anyone's going to take the time coding something so niche). There's definitely not going to be a "gamer" version of this card so the price is going to be hideous.

Originally Posted by M344587487

https://www.amd.com/en/graphics/work...on-pro-vega-ii


https://old.reddit.com/r/Amd/comment...card_infinity/


https://old.reddit.com/r/Amd/comment...rt_of_new_mac/

• Two MI60 chips on the same board with an 84GB/s infinity fabric link connecting them
• 128 CU's
• "Up to 64GB HBM2" meaning 2x16GB or 2x32GB

Each chip should have slightly more throughput than a Radeon VII when doing disjoint tasks due to the extra CU's. There is an outside chance that a single test could span both chips (not efficient, maybe not too detrimental to throughput in theory not that anyone's going to take the time coding something so niche). There's definitely not going to be a "gamer" version of this card so the price is going to be hideous.

https://www.amd.com/en/products/grap...eon-rx-5700-xt

[M344587487]

Navi like the RX 5700 above is on the RDNA architecture, something somewhat based on GCN but tailored more to graphics than compute. I expect it to be much more similar to current nvidia cards than AMD cards in that the single precision will make it performant for TF but low DP performance would make it a poor choice for PRP/P-1. I've heard mixed things about Navi and my expectations are accordingly low to mid. RDNA is going to be used in Samsung phones so the arch is scalable, if that translates to good power scaling in desktop parts it could be surprisingly effective for our niche.

Originally Posted by M344587487

Navi like the RX 5700 above is on the RDNA architecture, something somewhat based on GCN but tailored more to graphics than compute. I expect it to be much more similar to current nvidia cards than AMD cards in that the single precision will make it performant for TF but low DP performance would make it a poor choice for PRP/P-1. I've heard mixed things about Navi and my expectations are accordingly low to mid. RDNA is going to be used in Samsung phones so the arch is scalable, if that translates to good power scaling in desktop parts it could be surprisingly effective for our niche.

Anyway the new Navi GPUs require PCI 4.0, which means they need new mainboards.

[henryzz]

Originally Posted by SELROC

Anyway the new Navi GPUs require PCI 4.0, which means they need new mainboards.

Require or support? I have run a pcie 3 card in a 1.1 socket. It would surprise me if it won't run on current motherboards.

Originally Posted by henryzz

Require or support? I have run a pcie 3 card in a 1.1 socket. It would surprise me if it won't run on current motherboards.

Yes, probably, but with lower performance.

[M344587487]

They don't require PCIe 4.0 motherboards, it's a backwards compatible standard. A PCIe 4.0 compatible motherboard is required to use PCIe 4.0 but current PCIe 3.0 compatible motherboards will take these fine and run at PCIe 3.0 speeds. In fact for power efficiency we are probably better off using older motherboards or 3.0 speeds anyway, PCIe 4.0 and the signal boosting it requires bumps the chipset power requirements to the point of requiring a fan under load. There's only one, maybe two passively cooled x570 motherboards out there indicating that the chipset power consumption is probably 5-10 watts under load.

[kriesel]

Originally Posted by SELROC

Yes, probably, but with lower performance.

Could you post some numbers for linux and your gpu, of bus load?
On Windows 7 pro x64, my GTX1080, running CUDALucas, 125M LL, on a PCIe 2.0 connection, GPU-Z is showing only 1% bus interface load while the GPU load is 100% and the gpu memory controller load is 76%. Running gpuowl v6.5 on 332M PRP on the same setup, it's showing rapidly varying 4-50% bus interface load, steady GPU load 100%, GPU memory controller load steady 52%. Gpuowl V6.5 PRP, on same 125M exponent, gpu load 100%, gpu memory controller load 60%, bus interface load varying from 8-52% (22% average).

Originally Posted by kriesel

Could you post some numbers for linux and your gpu, of bus load?
On my GTX1080, running CUDALucas, 125M LL, on a PCIe 2.0 connection, GPU-Z is showing only 1% bus interface load while the GPU load is 100% and the gpu memory controller load is 76%. Running gpuowl v6.5 on 332M PRP on the same setup, it's showing rapidly varying 4-50% bus interface load, steady GPU load 100%, GPU memory controller load steady 52%.

Sorry I have omitted important information: in PRP case the bus load could only affect GEC data transfers I think.


I don't know GPU-Z, on linux there are various gpu diagnostic programs, with varying levels of confidence.

[kriesel]

Originally Posted by SELROC

Sorry I have omitted important information: in PRP case the bus load could only affect GEC data transfers I think.

I don't know GPU-Z, on linux there are various gpu diagnostic programs, with varying levels of confidence.

What I observe while running gpuowl 6.5 in GPU-Z is a rapid and significant bus load variation on the gpu, from one 2.5-second sensor sampling period to the next, faster than the ~9.5 second PRP block size (1000 iterations) period and far faster than the usual (~3.2 minutes) 20,000 iteration screen output period or the ~2.6 hour (1,000,000 iterations) GEC period of the 125M PRP. Don't know why. Does not occur in CUDALucas, and the gpu in question is not connected to a display. GPU-Z info at https://www.techpowerup.com/gpuz/

Originally Posted by kriesel

What I observe while running gpuowl 6.5 in GPU-Z is a rapid and significant bus load variation on the gpu, from one 2.5-second sensor sampling period to the next, faster than the ~9.5 second PRP block size (1000 iterations) period and far faster than the usual (~3.2 minutes) 20,000 iteration screen output period or the ~2.6 hour (1,000,000 iterations) GEC period of the 125M PRP. Don't know why. Does not occur in CUDALucas, and the gpu in question is not connected to a display. GPU-Z info at https://www.techpowerup.com/gpuz/

GPU-Z shows all information in one window, if you have a graphics interface on linux there is https://github.com/Eliovp/amdmemorytweak for AMD GPUs, also it can be used from the command line but I have not tested yet.