AMD Vega 10, Vega 11, Vega 12 and Vega 20 Rumors and Discussion

pTmdfx said:
But at least in Gen-Z's case, it is a problem in the realm of physical addresses. The VM space should be agnostic of it.
Click to expand...
The direct addressing component works with each device advertising the globally visible address space, and those ranges being mapped in the address spaces of the devices that are going to be accessing it, although the cap for the directly-addressed portion is 56 bits.

Transparently mapping and using DRAM and byte-addressable NVRAM in the same manner is a proposed use case.
 
Alessio1989 said:
How does the CPU (ie the driver) be able to access to the 49th bit of VAS if the x86 CPU cannot translate that address?
Click to expand...
The driver can test the 49 bit before using it though, if it would ever receive a flat address. But AFAIU it is not really a valid direct HSA address. It is a GCN specific implementation detail to support the image and sampler resources. Coarse-grained memory allocation (that goes to the GPU local memory) should lie inside the process VAS.
 
pTmdfx said:
The driver can test the 49 bit before using it though, if it would ever receive a flat address. But AFAIU it is not really a valid direct HSA address. It is a GCN specific implementation detail to support the image and sampler resources. Coarse-grained memory allocation (that goes to the GPU local memory) should lie inside the process VAS.
Click to expand...
This makes more sense ^_^
 
3dilettante said:
The direct addressing component works with each device advertising the globally visible address space, and those ranges being mapped in the address spaces of the devices that are going to be accessing it, although the cap for the directly-addressed portion is 56 bits.

Transparently mapping and using DRAM and byte-addressable NVRAM in the same manner is a proposed use case.
Click to expand...
I don't get your point though. These are going to be happened in the physical address space anyway, while the process VASes are an indirection layer on top of physical address space. In other words, a 48-bit VAS should not prohibit your ability to address resources in a physical address space that is larger than it, only except that a single process cannot address them all.

(It would require changes to the Linux kernel though, since Linux maps the entire range of physical memory into the kernel virtual address space.)
 
Last edited:
pTmdfx said:
I don't get your point though. These are going to be happened in the physical address space, while the process VASes are an indirection layer on top of physical address space. In other words, a 48-bit VAS should not prohibit your ability to address resources in a 56-bit physical address space, only except that a single process cannot address them all.
Click to expand...

I agree that it does not appear to be required, since the OS does not need to be modified and the MMU should map accesses to either DRAM, NVRAM, or another device's advertised address range.
I was addressing why there might be a desire to extend the virtual address range, which is that there are HPC and big data workloads that want applications to be able to address the memory devices attached to multiple nodes--with each node potentially loaded up with DRAM and an even larger pool of NVRAM. Gen-Z puts a higher theoretical ceiling for directly-referenced memory.
 
3dilettante said:
I agree that it does not appear to be required, since the OS does not need to be modified and the MMU should map accesses to either DRAM, NVRAM, or another device's advertised address range.
I was addressing why there might be a desire to extend the virtual address range, which is that there are HPC and big data workloads that want applications to be able to address the memory devices attached to multiple nodes--with each node potentially loaded up with DRAM and an even larger pool of NVRAM. Gen-Z puts a higher theoretical ceiling for directly-referenced memory.
Click to expand...
It would be too early to say OSes do not need to change though.
 
MDolenc said:
AFAIU SSG is a PCI-Ex device/function. CPU copies to it, GPU then reads/writes from it. Problem with SAN is that it's not like an SSD/HDD, it's more of a network card with additional protocols on top.
Click to expand...
In current form, but that form also lacked the flat addressing they mentioned for future products. In the case of Vega a more direct SoC implementation with the NoC/fabric might make sense. Base level SAN is block IO just like a standard drive, but often has filesystems and other protocols on top.
 
pTmdfx said:
Memory is byte addressable, not bit.

The virtual address space of AMD64 is 48-bit, unless AMD is going after Intel's 5-level paging extension (which still supports 48-bit for compatibility though).
Click to expand...
Thx (also to MDolenc). I was coming from the reported VM Bits in the drivers. There are certaily some more oddball bitnesses. While Nvidia since Fermi and AMD since GCN do support 40 bits per process (albeit with some drivers only 36 bits per resource), Intels IGPs exhibit very odd bitnesses: Skylake goes full circle with 48 per process (38 (!) per resource), but Haswell for example has 31 bits each. That's why I wasn't exactly sold on full bytes for adress space.
 


All this shows is that the card is working and driver QC is probably close to shipping.
I wish they had used a more punishing game than Battlefront, but if this is in Ultra settings + TAA then not even the Pascal Titan X can achieve solid 60FPS.
Though this could be a special new build of Battlefront with DX12.

But I guess tomorrow we'll know almost everything there is to know about the new cards.
 
I have not get time to watch if he precise the resolution or setting. look like V-sync was set anyway, so could be anything. Sadly dont tell us much about the perf.
 
lanek said:
hence why he was precise, ultra + TAA (not SMAA or FXAA )
Click to expand...
TAA only incurs a very modest performance hit, nevertheless in the three links the TitanX P can handle it with Ultra and TAA. In fact the card was averaging 56 fps at 7680x1440!

EDIT: in the hardware.fr link (from ToTTenTranz post), the card is clearly CPU limited, they used an 8 core 5960X but turned off HT, and the game uses HT very capably.
http://www.hardware.fr/articles/953-5/protocole-test.html
 
Last edited:
There isn't really enough in that short video to discuss really.
 
Malo said:
There isn't really enough in that short video to discuss really.
Click to expand...
Agreed:
ToTTenTranz said:
All this shows is that the card is working and driver QC is probably close to shipping.
Click to expand...


And Battlefront is probably one of the least CPU-dependent games out there, even though it's a DX11 game.

7KrJskc.png


So it's not a good showcase for RyZen either.
 
You must log in or register to reply here.
Back
Top