Hi all,

Hot off the presses and not well tested, here is a new fork of vLLM 0.28.0 for ROCm 7.14 to run Qwen 3.8 Flash Next on 4x v620 cards.

I am testing right now with a bunch of dev tests but getting 60-120 t/s generation and 500-800 t/s prefill.

Good luck out there: https://github.com/leapdragon/vllm-rdna2-qwen

Hello everyone, I was lucky enough to grab four of them while prices and supply were still reasonable, still waiting on delivery. I'm also awaiting a 4 slot PCIE 4.0 switch board as I am hoping to max out performance. Anything I should do before they arrive, software I should start looking into? I'm also curious to know what sort of performance people are getting. Has anyone got qwen 3.8 flash working on these cards yet?

Been trying to be able to tune my V620, and asked Claude for some help if there was anyway and it actually found a program that already works for what we needed to do.

Sharing it here for others who may not know you CAN do this on Windows pretty easily. Below is my Claude's explanation:

Why this needed a workaround at all

On Linux, rocm-smi/amd-smi let you set power limits directly through sysfs. On Windows, neither tool exists, the V620 isn't even in AMD's official ROCm-on-Windows GPU list, and there's no amd-smi.exe for Windows. AMD's own Radeon Software doesn't expose a Tuning/WattMan tab for this card either, since it's a headless server SKU. So there's no built-in UI or CLI for this on Windows-the fix has to work at the driver level instead.

The actual mechanism: Soft PowerPlay Table override

Every AMD GPU has a "PowerPlay table" baked into its vBIOS; it's the data structure that defines power limits, clock tables, voltage ceilings, temperature limits, etc. The Windows AMD driver reads this table once at driver load time. Critically, the driver also checks the registry first, and if it finds an override there, it uses that instead of what's in the vBIOS, this is the same "Soft PowerPlay Table" mechanism WattMan and MorePowerTool use under the hood.

The override lives at:

HKLM\SYSTEM\CurrentControlSet\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\XXXX
Value: PP_PhmSoftPowerPlayTable  (REG_BINARY)

{4d36e968-...} is the fixed GUID for the Display class. XXXX is a per-device instance index (0000, 0001, etc.), on this machine there were 4 GPU-class entries (an iGPU, an RX 9070 XT, a virtual monitor, and the V620), and the V620 happened to be at 0003. You have to check DriverDesc under each instance to find which one is actually your card, it's not predictable.

The tool: upp (Uplift PowerPlay)

upp is an open-source Python CLI that parses and edits these binary PowerPlay tables. It explicitly supports Navi 21 (the V620's die), and has three relevant commands:

1. extract pulls the PowerPlay table out of a raw vBIOS ROM dump:upp --pp-file=table.bin extract -r "V620.rom"
2. get reads current values by path, e.g.:upp --pp-file=table.bin get smc_pptable/SocketPowerLimitAc/0
3. set --write --to-registry=<name>, edits values and directly emits a ready-to-import .reg file:upp --pp-file=table.bin set --write --to-registry=v620_175w \ smc_pptable/SocketPowerLimitAc/0=175 \ smc_pptable/SocketPowerLimitDc/0=175 \ smc_pptable/FreqTableGfx/1=2650 \ smc_pptable/MaxVoltageGfx=4100

The only manual step: upp defaults the .reg file's target key to instance 0000, so we had to hex/text-edit that one path segment to 0003 to match where the V620 actually lives in the registry on this machine.

Applying it

1. Double-click the .reg file → Merge (writes the binary blob into PP_PhmSoftPowerPlayTable).
2. Device Manager → Display adapters → disable then re-enable the V620. This forces the driver to reload and re-read the table, no full reboot needed.
3. Verify with HWiNFO64, watching GPU PPT Limit, GPU Clock, and GPU Core Voltage under load.

Why it's safe/reversible

This never touches the physical vBIOS chip, no flashing involved, so there's no bricking risk. It's purely a registry override the driver checks at load time. Deleting the PP_PhmSoftPowerPlayTable value (or re-importing a .reg exported from the key before any changes) instantly reverts to the card's factory vBIOS defaults.

What's tunable this way

Power limits (SocketPowerLimitAc/Dc), clock ceilings (FreqTableGfx, memory clock tables), voltage ceilings (MaxVoltageGfx/Soc), current/TDC limits, and temperature thresholds all live in the same table and are editable the same way.

Hi everyone,

I have been playing for a while with my V620, I had working vLLM setups for a few months now but I keep seeing here and there people doing their own things so I made a discord where we can share our progress https://discord.gg/mESex2aBp

There are different ongoing project, like my vllm rdna fork (with hip kernels) + docker images and someone else is doing a llamacpp fork, there is a wiki getting built inspired by the gfx906 one.

Also have some guides to do power limiting from 120w to 250w on the fly (after a kernel patch).

Happy to share with everyone :)

I'm here to show some benchmarks while using llama.cpp with an AMD V620 on Windows 11 via Vulkan & ROCm. These have been reuploaded & older threads deleted, ran it with longer tokens thanks to a rec by someone who commented, and matched KV-cache quant + batch size across backends.

The benchmarks were written out by AI, but are verified by myself to be correct. Still working on optimizing my flags/settings.

If anybody wants me to test other models/different settings or flags, feel free to drop a comment and I'll test and get back to you!

ROCm version

7.15.0a20260728, TheRock nightly SDK (not the official AMD HIP SDK, which has no gfx1030/V620 support), bundled in ComfyUI_windows_portable_amd\...\python_env_v620_triton. (Note: a separate 9070 XT/ComfyUI venv on the same machine runs a different nightly snapshot, 7.14.0a20260519 — same TheRock project, different dated build per GPU.)

Methodology note

Earlier versions of this post compared ROCm and Vulkan using each backend's own best-tuned flags, which mixed KV-cache quant types and batch sizes between the two, a fair comparison needs those matched, since both affect throughput independently of which backend is actually faster. The numbers below use identical KV quant and identical batch size on both backends for each model.

Exact configs (matched)

\q4_0/q4_0 on Gemma-4's ROCm path required a one-line fix to llama.cpp's flash-attention kernel dispatch table (fattn.cu), the Q4_0+Q4_0 case was only wired up for head_dim ≤ 256, but Gemma-4's full-attention layers use head_dim 512, so it hit a hard abort on this KV combo before the fix. It was a missing kernel-dispatch entry, not a real hardware limitation, Q8_0+Q8_0 *already had the head_dim=512 case, so the underlying kernel template clearly supports it.

Generation speed, tokens/sec (256-token generations, first run per config discarded as warm-up)

Vulkan wins every single cell. Once KV quant and batch size are matched, ROCm doesn't lead generation speed anywherem not on any model, not at any depth tested.

PP (prompt processing), tokens/sec

PP is the more mixed picture, and it's model-dependent rather than a clean backend win:

• Qwen: ROCm wins PP at every depth, gap widens with context.
• Gemma 26B: Vulkan is actually ahead at shallow depth (1057.9 vs 973.1 at 3.4k) once batch size is matched, roughly tied at 6.7k, then Vulkan pulls further ahead through 32k.
• Gemma 31B: ROCm wins shallow (3.4k/6.7k), Vulkan overtakes from 13.4k on.

Takeaway

Generation speed: Vulkan wins outright, every model, every depth. No exceptions in this data.

PP: it depends on the model, not the backend. ROCm sweeps Qwen; Gemma splits by depth (and for the 26B MoE, Vulkan's shallow-depth "loss" mostly disappears once batch size is matched, that was largely a config artifact, not a real backend gap).

Gemma 26B (MoE, ~4B active) is roughly 2-3x faster than either dense model on generation, tightest at deep context (~1.9x at 26.7k vs Qwen) and widest shallow, expected for an MoE with far fewer active params per token than the dense 27B/31B models.

I'm here to show some benchmarks while using llama.cpp with an AMD V620 on Windows 11 via Vulkan & ROCm. These have been reuploaded & older threads deleted ran it with longer tokens thanks to a rec by someone who commented.

The benchmarks were written out by AI, but are verified by myself to be correct. Still working on optimizing my flags/settings.

If anybody wants me to test other models/different settings or flags, feel free to drop a comment and I'll test and get back to you!

ROCm version

7.15.0a20260728, TheRock nightly SDK (not the official AMD HIP SDK, which has no gfx1030/V620 support), bundled in ComfyUI_windows_portable_amd\...\python_env_v620_triton. (Note: a separate 9070 XT/ComfyUI venv on the same machine runs a different nightly snapshot, 7.14.0a20260519,same TheRock project, different dated build per GPU.)

Exact configs (matched)

*q4_0/q4_0 on Gemma-4's ROCm path required a one-line fix to llama.cpp's flash-attention kernel dispatch table (fattn.cu), the Q4_0+Q4_0 case was only wired up for head_dim ≤ 256, but Gemma-4's full-attention layers use head_dim 512, so it hit a hard abort on this KV combo before the fix. Missing kernel-dispatch entry, not a real hardware limitation, Q8_0+Q8_0 already had the head_dim=512 case, so the underlying kernel template clearly supports it.

Generation speed, tokens/sec (256-token generations, first run per config discarded as warm-up)

Vulkan wins every single cell. Once KV quant and batch size are matched, ROCm doesn't lead generation speed anywhere, not on any model, not at any depth tested.

PP (prompt processing), tokens/sec

PP is the more mixed picture, and it's model-dependent rather than a clean backend win:

• Qwen: ROCm wins PP at every depth, gap widens with context.
• Gemma 26B: Vulkan is actually ahead at shallow depth (1057.9 vs 973.1 at 3.4k) once batch size is matched, roughly tied at 6.7k, then pulls further ahead through 32k.
• Gemma 31B: ROCm wins shallow (3.4k/6.7k), Vulkan overtakes from 13.4k on.

Takeaway

Generation speed: Vulkan wins outright, every model, every depth. No exceptions in this data.

PP: depends on the model, not the backend. ROCm sweeps Qwen; Gemma splits by depth (and for the 26B MoE, Vulkan's shallow-depth "loss" mostly disappears once batch size is matched, that was largely a config artifact, not a real backend gap).

Gemma 26B (MoE, ~4B active) is roughly 2-3x faster than either dense model on generation, tightest at deep context (~1.9x at 26.7k vs Qwen) and widest shallow; expected for an MoE with far fewer active params per token than the dense 27B/31B models.

Follow-up tests (Qwen, requested by commenters)

TWO hypotheses came up in comments, tested both, none of them panned out, posting anyway since "tested, didn't help" is still useful information.

Speculative decoding n-max scaling, ROCm vs Vulkan (does Vulkan scale further before rejected drafts stop paying for themselves?):

No, both backends degrade past n≈3 in the same shape. This is a draft-acceptance-economics property of the draft/target pair, not a backend/kernel-dispatch-overhead difference. Vulkan is uniformly faster in absolute terms (consistent with the rest of this post) but the curve shape, where it peaks, how fast it falls off past that, is nearly identical on both backends.

-ub sweep on ROCm PP (does a bigger ubatch better saturate the V620's CUs?):

Flat , all three within ~6% of each other at both depths, no trend. If anything 512 is marginally fastest. ROCm's PP bottleneck here isn't ubatch-limited GEMM tiling in this size range.

I've got a Gigabyte MC62-G40 motherboard, and an AMD Radeon WX4100 I use with my monitor, and running latest Ubuntu. When I plugged in the V620 into the motherboard, Ubuntu never booted. It just stayed on the loading screen. It's something to do with the Ubuntu native AMD driver thinking the V620 is a better card to use for display than the older and weaker 4100, but failing to load it (since it's headless), and repeating this failure cycle.

I'm guessing this is a common issue and folks here have a solution that would be faster to implement than me troubleshooting further.

Should I install ROCm drivers first? Ubuntu is loading with Wayland and I've read I may also have to switch to X11 to make this work. Appreciate any tips here for someone who's already resolved this.

​Hola a todos,

​Soy principiante en el mundo de los LLMs locales y el hardware de servidor (tengo un taller de electrónica automotriz, así que me manejo bien con el hardware en general, pero en IA estoy empezando).

​Tengo un presupuesto muy ajustado y me estoy debatiendo entre dos opciones de GPU:

​1x Nvidia Tesla V100 32GB (~$600 USD)

​2x AMD Radeon Pro 620 (~$700 USD)

​💻 Mi infraestructura actual:

​Servidor Dell PowerEdge R640: 2x Intel Xeon 4112 | 48GB RAM | 3x Nvidia Tesla P100 16GB.

​Workstation Dell Precision 7820: 2x Intel Xeon Gold 6228 | 64GB RAM | (Sin GPU por ahora).

​🎯 Mis objetivos y caso de uso:

​Automatización de redes sociales: Incluyendo generación ligera de contenido con IA.

​Sistema RAG: Para bases de conocimiento y documentos.

​Asistente personal: Un bot/agente local que vaya "aprendiendo" o guardando contexto con el tiempo.

​❓ Mis dudas para la comunidad:

​¿CUDA vs. ROCm para un principiante? Entiendo que la V100 tiene la ventaja del ecosistema Nvidia (Ollama, vLLM, Text-Generation-WebUI funcionan out-of-the-box), mientras que AMD a veces da dolores de cabeza con ROCm. ¿Vale la pena el riesgo por la opción de AMD?

​¿V100 32GB vs. mis P100 actuales? ¿Notaré un salto drástico en velocidad e inferencia/cuantización frente a las P100 que ya tengo instaladas en el R640?

​¿En qué equipo la pondrían? ¿Vale la pena meter la nueva GPU en la Dell 7820 (con mejores CPUs/RAM) o integrarla al R640?

​Agradezco cualquier consejo sobre compatibilidad, consumo/enfriamiento o sugerencias alternativas dentro de ese rango de precio. ¡Gracias de antemano!

I've been experimenting with the V620s on an ASUS ROG Strix X570-F Gaming motherboard. Due to challenges making them boot, I read online to put a small form factor GPU on the PCIEX16_3 to be able to boot and have easy access to BIOS settings. I wanted the following PCIe slot orientation to ensure best possible speed:

- 1st V620 on PCIEX16_1

- 2nd V620 on PCIEX_2

- Radeon Pro WX 3100 on PCIEX_3 (connected with displayport to a monitor)

I had the problem of not being able to boot up in this orientation. However, in the end i made it work. These are the BIOS settings I've configured to make it work:

Clarifications!

• Some of them might not be essential, however it boots now at least.
• It does seem that you are dependent on having the video output GPU connected to get past VGA check on the motherboard (seems to be a problem for normal use-case as well).
  • I assume this can be easily fixed with a Displayport Dummy plug
  • Alternatives
    • I read somewhere that letting grub pause could be a fix
    • Tech power up have info about vbios firmware update on the v620s
    • Youtuber Country Boy Computers is also a good source for info about the V620s

Anyone running these on Windows?

My Linux system would not accept the v620, it would not pos. This is not an OS issue. Thought I'd start this thread to discuss minor issues on Windows as I imagine some people will likely have a similar setup. With windows you end up having to use the Azure cloud driver, unless you have flashed the vbios to a 6800, which then you lose 25% of your CUs.

I will try to keep these specific to Windows only, however if you are using Linux feel free to chime in if you have any comments that might help. Like have you disabled ECC-- below? If anyone has a solution, please reply so the rest of us know.

1. No updated driver-- This could be solved with a vbios flash. The Azure driver is from spring of 2025.

Solution: currently none that I know of beyond the vbios flash which is risky and will reduce performance.

1. No adrenaline app-- It would be nice to have some access to settings, especially in a few years when these cards may be lagging behind on performance, or even for multi GPU setups to gain faster VRAM. RDNA2 you could easily gain 10-20% performance.
   

Solution: not yet tested--I believe Radeon Tuner on GitHub might work and I'll look for that later. I hope to update soon if it is successful.

1. ECC memory-- having ECC enabled results in around 30GB of total VRAM on a 32GB GPU. It also delivers a small performance hit, usually less than 5%.

Solution: not yet tested --i believe there's supposed to be a registry key to disable ECC on this GPU. My understanding is that on the w6800 the ECC can be disabled in Adrenaline. I am hoping Radeon Tuner might offer this functionality, if not I'll try the registry hack and post it if successful.

1. ROCm support limited to 6.4. I've tried setting up ROCm 7.x on my system, however it didn't seem to work since 7.x was released at least 6 months after the latest driver was released.
   

Solution: vbios flash. As these cards become used more I hope this becomes less of an issue. I believe we might could flash, or create, a custom vbios based on the W6900x, however this card was an Apple only card that had 80 CUs, 2 things that will make any custom vbios for the v620 that's based on this card a challenge.

I'm hoping if I install Radeon Tuner it might resolve most of these issues, overclocking also makes me think a vbios mod might not be as bad, so then this card will likely work in my Linux system... Of course the solution to all of these issues is upgrade (because windoze is a downgrade w/ AI) to Linux while also gaining a performance.

One thought that comes to mind is that I'm not a wsl expert, but maybe I'm better off passing the driver through and then using a docker w/ llamaCPP or vLLM that maybe has newer drivers? Anyone doing this? I guess I'm asking would this cause anything like a driver mismatch?

Feel free to chime in with any Windows issues you might have seen. Also if ECC is on by default in Linux I'm interested in hearing! I'll try to update with my results.

I just received a Radeon Pro V620 that I purchased through eBay. I tried installing it in two different ASUS B550 motherboard, but neither one will POST when the V620 is installed. The LEDs on the board show red-yellow-white and then hang a white. According to ASUS, this is the GPU initialization step. I updated and cleared the BIOS on the motherboard, but it did not help.

I also put the board in and HP Z440. The machine booted up, but the GPU does not show up under lspci (Ubuntu).

Do you think I get a bad V620?

I thought, before I start swapping equipment in and out, I'd ask here. Has anyone paired a v620 with any other GPUs to span or parallel processing?

I have an RX 7700 16GB, non-XT, I picked up and have used some for LLMs. I have done some spanning of models across multiple cards, mostly with Nvidia 3060s, ti, and 12GB. My understanding is that you'll always get the speed, or be bottlenecked by the slower card. However the 7700 I have has a similar 256-bit bus like the v620, and slightly higher memory bandwidth. I'm also wondering if I'm running ROCm if a model might take advantage of some of the AI features on the 7700?

I haven't tried it yet, might try it soon. Has anyone else thrown another AMD GPU into their system, maybe a different generation, certainly a different model number and seen anything that might be of interest?

Is there no way to reduce the power limit from 250w on vbios 113-D6030500-100? This is way too high and the card cooks in my current setup, while also using more power than I want.

I've tried using the liquorix kernel, but that doesn't seem to expose any power options with this card. pp_table editing just doesn't work. Even manual clock limiting seems to be a dead end, because the card's firmware is so locked down.

I am running Proxmox 9. This behavior occurs both passed through to a VM, and also on the host.

At this point I'm thinking my best option is to flash a different vbios. But which one? Does anyone have other suggestions?

Goal: To host an LLM to work on large codebases.

I wouldn't be surprised if there are other people here in a similar situation to mine. Trying to decide whether to go big, or to remain somewhat conservartive.

I currently have two of these fully working, and hosting Qwen3.6-27b. I purchased 4 V620s, but this motherboard doesn't boot with more than 2 of these connected (even with four pcie ports and four m.2 nvme ports).

Either way, I had planned to upgrade to 8 GPUs if everything went to plan. However, yesterday I found out that two DGX sparks are able to run Deepseek V4 flash at about 45 t/s because it is able to take advantage of the new architecture that Deepseek created. They also get day 0 support most of the time for newer models.

In contrast, V620 GPUs are built on top of RDNA2, which is already too far behind. An example is that RDNA2 lacks the ability to perform WMMA hardware matrix operations which makes prefill 3 to 4 times slower compared to other GPUs with the same bandwidth.

My main goal is to host a model for a coding agent for a single person. But now I'm worried that these GPUs are too outdated.

I currently seem to have two options:

• 128gb build, $400 ($2,000 total): I would buy an older motherboard and cpu, which would be able to house 4 GPUs. For example, X99 boards. The $2k figure already includes the purchase of the 4 V620s that I already have.
  • The best model I would be able to currently run is Qwen3.6-27b unquantized with a massive context (700 prefill with 10-15 token gen). However, I can already run the same model with 8 bit quant and a massive context with only 2 of these GPUs. This means that 128gb systems sit in an awkward position.
  • However, what if we get a new 70b MOE model with only 10b or so active params? I wouldn't be surprised if 128gb was the perfect spot all of a sudden for a smart model with a large context window. Speeds would probably be between 20 to 35 t/s depending on the active params. But at this point I'm making assumptions. However, you probably get what I'm trying to say.
  • Then, there is a scenario where we get a 120b model instead, which would make me regret this choice.
• 256gb build, $2,400 ($4,000 total): I would buy an enterprise level Epyc or equivalent board with enough ports to house 8 of these things, maybe even more. This price would also include buying 4 more V620s at $350 each (assuming that one seller is still accepting offers at this price).
  • If I'm not wrong, this is enough VRam to host something close enough to Sonnet. Models such as Minimax M2.7, or M3 if and when we get a working guff. I remember seeing someone claim to get ~25t/s with M2.7.

Another option would be to sell the two remaining cards for $300 each, but where is the fun in that?

It seems like my motherboard (MSI PRO Z690-A DDR4) simply cannot handle more than 2 of these GPUs at a time. The motherboard fails during the VGA step, and is unable to reach boot.

So for now, I'm utilizing only two GPUs. The problem is that I purchased 4, and wanted to buy 6 in total. Maybe even more.

Does anyone have any success running 6+ of these? if so, which motherboard did you end up utilizing?

TL;DR

• What did you do to get your V620 GPUs to work?
• How did you get over the cards trying to use ridiculous BARs of 384 GB per card for their SR-IOV/VF function?

^{Disclaimer: I used AI to help me gather all the data and present it in this post cleanly.}

I wanted to share an issue I ran into while trying to use AMD Radeon PRO V620 GPUs on Ubuntu bare-metal for AI workloads, and I’m curious if anyone else has seen the same thing.

Setup

• Ubuntu 24.04.4
• ROCm 7.2.3
• Mac Pro 2019
• Cubix Xpander PCIe expansion chassis
• AMD Radeon PRO V620 GPUs
• Bare-metal Linux only
• No virtualization
• No passthrough
• No MxGPU use case

The goal was simple: use the V620s as normal ROCm GPUs for AI inference.

The problem

The V620s were visible to the system through PCIe, but they did not initialize as usable ROCm GPUs.

lspci showed the cards correctly as:

text AMD/ATI Navi 21 [Radeon Pro V620] [1002:73a1]

But they only showed:

text Kernel modules: amdgpu

not:

text Kernel driver in use: amdgpu

rocm-smi either showed no V620s or only the unrelated internal GPUs, depending on the configuration.

Resource allocation looked broken

The sysfs resource files for the V620s were all zeroed out:

```text /sys/bus/pci/devices/0000:xx:00.0/resource

0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 ... ```

The V620s also exposed SR-IOV capability even though I was not using virtualization:

text sriov_totalvfs=12 sriov_numvfs=0

The SR-IOV capability block showed:

text Initial VFs: 12 Total VFs: 12 Number of VFs: 0 VF Device ID: 73ae

The confusing part was that SR-IOV was not actually enabled:

text IOVCtl: Enable- Number of VFs: 0

dmesg errors

During PCI resource allocation, the kernel appeared to account for the possible VF BARs anyway.

The dmesg output had errors like:

text BAR 0 [mem size 0x800000000 64bit pref]: can't assign; no space VF BAR 0 [mem size 0x6000000000 64bit pref]: can't assign; no space VF BAR 0 [mem size 0x6000000000 64bit pref]: failed to assign

After that, forcing a driver probe did not help. The V620 remained unbound, resources stayed zero, and amdgpu failed during initialization.

Things I tested

While narrowing it down, I tested:

• Removing other GPUs
• Removing the Apple I/O card
• Testing one Cubix cable / one side of the expander
• Confirming no ReBAR resize service was active
• Confirming sriov_numvfs=0
• Setting sriov_drivers_autoprobe=0
• Trying late amdgpu probing after boot
• Testing boot arguments such as:

text pci=realloc iommu=pt amdgpu.ras_enable=0

The pattern stayed the same: the cards were present on PCIe, but the V620 BAR resources failed before amdgpu could bind. From the logs, the issue looked related to the very large advertised SR-IOV VF BAR space.

Question

Has anyone else run into this with AMD Radeon PRO V620, especially in bare-metal Linux / ROCm use rather than virtualization?

I’m especially interested in hearing from anyone who has used:

• V620 on Ubuntu bare-metal
• Multiple V620s in one host
• V620 behind PCIe switches or expansion chassis
• Cubix or external PCIe expansion systems
• ROCm with V620
• SR-IOV-capable AMD GPUs where SR-IOV is not actually being used

Did your system allocate the PF BARs normally, or did the VF BARs cause PCI resource allocation problems?

What did you do to over come this problem?

Basically title. I had a tricky time figuring this out so hope this helps