VOGONS


AMD drops the mic

Topic actions

Reply 261 of 279, by F2bnp

User metadata
Rank l33t
Rank
l33t

There's been an interesting development in which Nvidia's driver apparently doesn't scale beyond 4 cores. Using an AMD GPU alleviates that and makes the Ryzen CPUs run a lot better, closing the gap in gaming between the 7700k substantially. You can see it in the Anandtech review as well, check out GTX 1060 vs RX 480 in Rocket League, a DirectX 9 title(!).

AdoredTV "discovered" it apparently and since then other publications and benchmarkers have picked up on it. https://www.youtube.com/watch?v=0tfTZjugDeg

Reply 262 of 279, by Scali

User metadata
Rank l33t
Rank
l33t
F2bnp wrote:

You can see it in the Anandtech review as well, check out GTX 1060 vs RX 480 in Rocket League, a DirectX 9 title(!).

I think it's jumping to conclusions based on a single outlier.
There's no way of knowing why that is. It doesn't necessarily have to do with the driver either. It could be a specific sequence of draw calls/states that leads to serialization on one architecture, but not on the other (so you can't 'fix' that in the drivers, it is what it is. AMD has that issue in DX11 with GCN, which is why they can't scale with deferred contexts on separate threads).

I would say it's quite peculiar that we see a DX9 title here. I wouldn't expect NV or AMD to still bother optimizing their drivers for the latest DX12+ GPUs for DX9 games. The performance and scaling in DX9 is probably all over the place. It doesn't seem to happen in any DX11/DX12 titles.

Another thing I find somewhat peculiar is that no Core i7s were included in the results. At the very least it would be interesting to see if the addition of HT would change anything in terms of multithreaded scaling. After all, they also included the Ryzen 7 for reference.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 264 of 279, by Scali

User metadata
Rank l33t
Rank
l33t

Really, those YT videos are usually a bunch of nonsense. It's a waste of time, these people don't really know what they're talking about.

The real reason why AMD can't support it is because of the way they handle rendering states:
They use actual commands that they insert into the command stream during execution.
Now the problem for them with DX11 is: you don't know when these deferred command lists are actually executed, ergo you don't know what state the GPU is going to be in.
This means that they have to postpone the generation of the final GPU-native rendering buffer until it is actually executed, basically serializing the workload.

Of course, with clever driver work, you may still be able get around that somewhat, by using some placeholders in the stream and some self-modifying code or such. But AMD never bothered with that, and just told developers not to use the feature.

NV's hardware is fundamentally different here, and therefore doesn't suffer from that issue. It's far simpler for them to compile deferred commandlists directly to GPU-native code.
And they even went beyond that: they found ways to speed up even 'single-threaded' DX11 code with multiple threads inside the driver.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 265 of 279, by TELVM

User metadata
Rank Oldbie
Rank
Oldbie

I post the video @ 22:59. The video is 19 minutes long (and quite interesting). Yet by 23:09 Scali already "knows" that it's "a bunch of nonsense". 🤣

Let the air flow!

Reply 266 of 279, by F2bnp

User metadata
Rank l33t
Rank
l33t

I don't think he bothered with that video I posted either, since as he said " It doesn't seem to happen in any DX11/DX12 titles."

Reply 267 of 279, by Scali

User metadata
Rank l33t
Rank
l33t

I've watched the relevant parts of the video, and it went on about differences in hardware scheduling. Which is NOT the problem, as I explained above (if anything, hardware scheduling should make it easier to execute deferred command lists, not harder).
Not sure what your problem is anyway, I clearly explained it, and clearly the video says other things (unless I happened to miss the part where they explain how states are managed inside native command buffers?). So why attack me personally about whether or not I watched the video, instead of commenting on the actual information I posted?
Nevermind, I already know the answer.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 268 of 279, by Carlos S. M.

User metadata
Rank Oldbie
Rank
Oldbie

Seems like a new bug was discovered on Ryzen related to the VME and legacy OSes (affects both physical and VMs)

VME Broken on AMD Ryzen

What is your biggest Pentium 4 Collection?
Socket 423/478 Motherboards with Universal AGP Slot
Socket 478 Motherboards with PCI-E Slots
LGA 775 Motherboards with AGP Slots
Experiences and thoughts with Socket 423 systems

Reply 269 of 279, by Carlos S. M.

User metadata
Rank Oldbie
Rank
Oldbie

Also. AMD teased Threadripper, their new HEDT plataform, up to 16C/32T Ryzen CPUs and quad channel RAM

https://www.youtube.com/watch?v=VUuuuah2md8

What is your biggest Pentium 4 Collection?
Socket 423/478 Motherboards with Universal AGP Slot
Socket 478 Motherboards with PCI-E Slots
LGA 775 Motherboards with AGP Slots
Experiences and thoughts with Socket 423 systems

Reply 270 of 279, by Jade Falcon

User metadata
Rank BANNED
Rank
BANNED
Carlos S. M. wrote:

Also. AMD teased Threadripper, their new HEDT plataform, up to 16C/32T Ryzen CPUs and quad channel RAM

https://www.youtube.com/watch?v=VUuuuah2md8

Come on AMD. Make a server version. It will kill Xeon's

Reply 271 of 279, by snorg

User metadata
Rank Oldbie
Rank
Oldbie
Jade Falcon wrote:
Carlos S. M. wrote:

Also. AMD teased Threadripper, their new HEDT plataform, up to 16C/32T Ryzen CPUs and quad channel RAM

https://www.youtube.com/watch?v=VUuuuah2md8

Come on AMD. Make a server version. It will kill Xeon's

Ask, and ye shall receive:

http://hothardware.com/news/amd-naples-zen-ar … tacenter-market

Looks like this is the official name for the Naples 32 core part. The Vega specs are giving me a massive chub too:

http://hothardware.com/news/amd-radeon-rx-veg … -16gb-hbm2-4k60

Reply 272 of 279, by Joey_sw

User metadata
Rank Oldbie
Rank
Oldbie
snorg wrote:
Ask, and ye shall receive: […]
Show full quote

Ask, and ye shall receive:

http://hothardware.com/news/amd-naples-zen-ar … tacenter-market

Looks like this is the official name for the Naples 32 core part. The Vega specs are giving me a massive chub too:

http://hothardware.com/news/amd-radeon-rx-veg … -16gb-hbm2-4k60

AMD has been remain silent about VME in Ryzen thing, so its wonder me if the newcoming Zen based Epyc would exihibit similar flaws?
Its must be hillarious when thats would actually happened.

-fffuuu

Reply 273 of 279, by awgamer

User metadata
Rank Oldbie
Rank
Oldbie

Servers are where the broken VME hits even bigger.

Reply 274 of 279, by ratfink

User metadata
Rank Oldbie
Rank
Oldbie

Backwards compatibility to 32 bit OS [when there seems an easy workaround anyway] doesn't sound like a deal-breaker for power users which are presumably where the money mostly lies.

Reply 275 of 279, by awgamer

User metadata
Rank Oldbie
Rank
Oldbie

I don't know where you get your info but servers is where the money mostly lies.

Reply 276 of 279, by ratfink

User metadata
Rank Oldbie
Rank
Oldbie

Sure, and i question whether all that many new servers will be required for VMs running 32 bit let alone 16 bit operating systems.

Btw i dont have an info source, i make it up as i go along.

Reply 277 of 279, by sf78

User metadata
Rank Oldbie
Rank
Oldbie

The last 32-bit OS (server or workstation) I worked with was around 2011 and Windows Server 2008 R2 had already been out for quite some time. I do understand the need to use a 32-bit OS in some scenarios, but those don't require any of the new CPU's to run properly.

Reply 278 of 279, by appiah4

User metadata
Rank l33t++
Rank
l33t++

Regardless, it looks like the VME issue can be fixed in microcode anyway so it will probably be a nonissue soon.

Reply 279 of 279, by Azarien

User metadata
Rank Oldbie
Rank
Oldbie
sf78 wrote:

I do understand the need to use a 32-bit OS in some scenarios, but those don't require any of the new CPU's to run properly.

Sometimes you need *new* machines, and still be able to run 32-bit OS on them.

It's one thing if AMD or Intel announced that their new CPU wouldn't run 16 and 32-bit OS'es, It's another when it's supposed to work but doesn't.

And it's not really possible to remove legacy CPU modes without breaking all existing 64-bit OS'es and bootloaders.