Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There’s no reason a pass through GPU configuration in a vm would have lower graphical fidelity.


There is a reason but it would only harm particularly poorly written games and even then a single digit percentage.

To excercise that you need a lot of separate memory transfers. Tiny ones. Games tend to run bulky transfers instead of many megabytes.

Memory bandwidth and command pipe should not see an effect even with the minimally increased latency, on any HVM.


Again with the caveat that this is specific to dom0 virtualization taking advantage of full hardware acceleration VT-d/VT-x, etc, what you say isn’t even necessarily the case.

With modern virtualization tech, the hypervisor mainly sets things up then steps out of the way. It doesn’t have to involve itself at all in the servicing of memory requests (or mapped memory requests) because the cpu does the mapping and knows what accesses are allowed or aren’t. The overhead you’re talking about is basically traversing one extra level in a page table noticeable only on micro benchmarks when filling the tlb or similar - this is a change in performance you might encounter a micro-regression in (without any virtualization to speak of) even when going from one generation of cpu architecture to the next.

Theoretically, the only time you’ll have any overhead is on faults (and even then, not all of them).

Of course I guess you could design a game to fault on every memory request or whatever, but that would be a very intentionally contrived scenario (vs just plain “bad” code).


Hello ComputerGuru,

As you may understand: there's more to graphical fidelity than just the GPU itself.

CPU<->GPU bandwidth (and GPU memory bandwidth) are also important.

There is a small but not insignificant overhead to these things with virtualisation: VMs don't come for free.


"Pass through GPU configuration" means that GPU memory is mapped directly into guest address space in hardware.

Bandwidth from a VM partition should be identical to that from the root partition.


I don’t understand what you’re trying to imply here.

Are you seriously suggesting that I chose to downgrade the graphics on the XB1 because I felt like it, and that dozens of other AAA game studios did the same thing?

Our engine was Microsoft native, by all rights it should have performed much better than PS4.

If you’re going to argue you’ll have to do a lot better than that since I have many years of lived experience with these platforms.


OK, you have a technical disagreement. No need to take it personally.

You may be right - you probably have more experience with this particular thing than I do.

I can't answer for the performance of the XB1, but I am curious what % reduction in GPU memory bandwidth you observed due to virtualization.

Did you have a non-virtualized environment on the same hardware to use for comparison?


I didn't take it personally, i just think you're presenting ignorance as fact and it's frustrating.

Especially when seemingly it comes from nowhere and people keep echoing the same thing which I know not to be true.

Look, I know people really love virtualisation (I love it too) but it comes with trade-offs; spreading misinformation only serves to misinform people for.. what, exactly?

I understood the parents perspective, GPU passthrough (IE; VT-d & AMD-Vi) does pass PCI-e lanes from the CPU to the VM at essentially the same performance. My comment was directly stating that graphical fidelity does not solely depend on the GPU, there are other components at play, such as textures being sent to the GPU driver, those textures don't just appear out of thin air, they're taken from disk by the CPU, and passed to the GPU. (there's more to it, but usually I/O involves the CPU on older generations)

The problem with VMs is that normal memory access's take on average a 5% hit, I/O takes the heaviest hit at about 15% for disks access and about 8% for network throughput (ballpark numbers but in-line with publicly available information).

It doesn't even matter what the exact precise numbers are, it should be telling to some degree that PS4 was native and XB1 was virtualised, and the XB1 performed worse with a more optimised and gamedev friendly API (Durango speaks DX11) and with better hardware.

It couldn't be more clear from the outside that the hypervisor was eating some of the performance.


I guess I should clarify that my point was purely in abstract and not specific to the XBox situation.

Of course in reality it depends on the hypervisor and the deployed configuration. Running a database under an ESXi VM with SSDs connected to a passed-through PCIe controller (under x86_64 with hardware-assisted CPU and IO virtualization enabled and correctly activated, interrupts working correctly, etc) gives me performance numbers within the statistical error margin when compared to the same configuration without ESXi in the picture.

I haven’t quantified the GPU performance similarly but others have and the performance hit (again, under different hypervisors) is definitely not what you make it out to be.

My point was that if there’s a specific performance hit, it would be pedantically incorrect to say “virtualizing the GPU is the problem” as compared to saying “the way MS virtualized GPU access caused a noticeable drop in achievable graphics.”


Sorry, I don't think I implied virtualising the GPU is the problem.

I said "the fact that it's a VM has caused performance degradation enough that graphical fidelity was diminished" - this is an important distinction.

To clarify further: the GPU and CPU is a unified package and the request pipeline is also shared, working overtime to send things to RAM will affect GPU bandwidth, so overhead of memory allocations that are non-GPU will still affect the GPU due to that limited bandwidth being used.

I never checked if the GPU bandwidth was constrained by the hypervisor to be fair, because such a thing was not possible to test, the only corrolary is the PS4 which we didn't optimise as much as we did for DX and ran on slightly less performant hardware.


I always figured texture loading from disk was mostly done speculatively and during the loading screen, but what do I know.

Anyway, a 5% memory bandwidth hit does not sound to me like a huge deal.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: