AMD Posts Open-Source Linux Driver Support For "NAVI 14" GPU

[QuImUfu]

and yes, I had forgotten about VSR on the windows driver, it could be that feature making its way into the product line.

VSR is in all Linux graphics drivers that support xrandr for **ages**. xrandr --output DVI-1 --scale 1.5x1.5 --auto --panning 1920x1536 --fb 1920x1536 gives me 1920x1536 resolution downscaled to 1280x1024 (my monitors resolution) in games.
I hope virtual display would enable me to e.g. put another GPU in my pc, start a Xorg instance on that "virtual display" and then stream it over kmsgrab and vaapi to another device, so i could have full, virtually latency-free access to my desktop pc anywhere in my house, without having to buy another (expensive) monitor that is not used. Or put my PC in the cellar and have only a raspberry pi(or similar) in my room, preventing heat production and noise.

If it can do multiple displays i could even stream each one to a different location.
For that to be useful one would need proper multi seat support in Xorg. if that would be a thing, i could replace all PC's/Static Laptops's in my house with a Raspberry pi(or similar), reducing costs (they are only used for browsing anyway, so them getting a display should not hinder my performance significantly) and power consumption. Additionally bursty workloads (because that one PC would be much better than any of the current ones) would profit on all of these replaced PC's and because everyone is often accessing similar programs caching would work even better. Because there is no VM the usual drawbacks of additional memory usage(duplicated services) and fixed resource distribution (e.g. VM1 has 3gb ram and 4 cores, VM2 13gb and 12 cores) do not exist. IMO VM's are only useful if you do not trust the other users.

[ernstp]

modinfo amdgpu says:
parm: virtual_display:Enable virtual display feature (the virtual_display will be set like xxxx:xx:xx.x,x;xxxx:xx:xx.x,x) (charp)

This is just a standard software feature that's supported by all other families already and nothing special.

[entropy]

<sarcasm>Will this driver be as stable as vega's one?</sarcasm>

Can you be a bit more specific please.

What instabilities are you talking about?

Currently, I still run a Radeon HD 7950 and it's completely stable.
I want to upgrade to Navi in the foreseeable future.
Should I expect issues with stability?

[QuImUfu]

This is just a standard software feature that's supported by all other families already and nothing special.

Oh, what does it do and how can it be used?

[ernstp]

Oh, what does it do and how can it be used?

https://lists.freedesktop.org/archiv...st/001058.html :
The Virtual Display feature is to fake a display engine in amdgpu kernel driver, which allows any other kernel modules or user mode components to work as expected even without real display HW. User can get the desktop/primary surface through remote desktop tools instead of displaying HW associated with the GPU. The virtual display feature is designed for following cases: 1)Headless GPU, which has no display engine, while for some reason the X server is required to initialize in this GPU; 2)GPU with head (display engine) but Video BIOS disables display capability for some reason. For example, SR-IOV virtualization enabled Video BIOS often disables display connector. Some S-series Pro-Graphics designed for headless computer also disable display capability in Video BIOS; 3)For whatever reason, end user wants to enable a virtual display (don’t need HW display capability).

[boxie]

Can you be a bit more specific please.

What instabilities are you talking about?

Currently, I still run a Radeon HD 7950 and it's completely stable.
I want to upgrade to Navi in the foreseeable future.
Should I expect issues with stability?

The vega drivers were a bit wobbly at the start. I have been riding padoka-ppa (git) for most of this year and it has been very stable so far.

[asdfgh]

Can you be a bit more specific please.

What instabilities are you talking about?

Frankly speaking I'm not an owner of any "big" vega (56, 64 or 7). I have a 2400G APU and it's terribly unstable. Usually when I play Mudrunner, but since yesterday I've being hit by "[gfxhub] VMC page fault" errors (the first bug report was on 2018-02-26).

From time to time I'm thinking about buying a new more or less powerful videocard, but maybe it's better to wait a year more to see what Intel will propose.

[entropy]

Frankly speaking I'm not an owner of any "big" vega (56, 64 or 7). I have a 2400G APU and it's terribly unstable. Usually when I play Mudrunner, but since yesterday I've being hit by "[gfxhub] VMC page fault" errors (the first bug report was on 2018-02-26).

I see.

https://bugs.freedesktop.org/show_bug.cgi?id=105251

There were quite some AMD devs trying to help but at some point they just left and never came back.
Issue seems to persist.
Hmm, very unfortunate, indeed.

[bridgman]

Frankly speaking I'm not an owner of any "big" vega (56, 64 or 7). I have a 2400G APU and it's terribly unstable. Usually when I play Mudrunner, but since yesterday I've being hit by "[gfxhub] VMC page fault" errors (the first bug report was on 2018-02-26).

Is there a big ticket for this ? I didn't see anything in bugzilla for Mudrunner but you mentioned "first bug report was on 2018-02-26". VMC page fault errors are not a specific bug, they just mean that something in the application or driver accessed memory that it didn't own, and that could have dozens or hundreds of different root causes.

Did you or your system updater change any files yesterday between working and not working ? I wouldn't expect the system to just start generating errors on its own.

https://bugs.freedesktop.org/show_bug.cgi?id=105251

There were quite some AMD devs trying to help but at some point they just left and never came back.
Issue seems to persist.
Hmm, very unfortunate, indeed.

Reading through the bug ticket it appears the primary problem (VM faults when running cemu under Wine) was fixed in cemu upstream, and what is left appears to be a collection of unrelated problems that only have VM faults in common.

[entropy]

Reading through the bug ticket it appears the primary problem (VM faults when running cemu under Wine) was fixed in cemu upstream, and what is left appears to be a collection of unrelated problems that only have VM faults in common.

I see. So I was confused by the bug ticket not closed.