Language:

en_US

switch to room list switch to menu My folders
Go to page: First ... 56 57 58 59 [60] 61 62 63 64 ... Last
[#] Sat Apr 25 2020 23:20:27 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


after a ridiculously long deep dive into linux graphics stack details, these GPU hangs appear to be related to font subpixel antialiasing, and the XRender extension. GPU Hangs triggered by a certain Java app, and they go away when adding -Dsun.java2d.xrender=false

I could probably disable the XRender extension entirely in xorg.conf, but I'm reading that some apps still require it in order to function correctly.

[#] Wed Apr 29 2020 19:16:22 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


got a pretty good handle on these issues... they appear to be specific to the Ice Lake GPU, related to SIMD code generated by the shader compiler, and there are a few different workarounds that help out or fix. Not a kernel issue, this is all userspace mesa driver stuff.

kernel 5.6 is looking good to go...

[#] Wed May 13 2020 14:02:59 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

I could probably disable the XRender extension entirely in xorg.conf,

but I'm reading that some apps still require it in order to function
correctly.

I'm wondering how long it will be before we can finally make the jump from Xorg to Wayland for real. Every major toolkit seems to support it now, but it still seems perpetually in a state of "just about there, we'll switch Real Soon Now"

My hardware is new (less than six months old) but it seems I just missed the new IOMMU technology ... from what I understand this is the beginning of finally being able to virtualize the GPU and run it in a KVM/QEMU guest at bare metal speed. That would be pretty cool. I think it's a low end version of what they're doing on servers, to provide server-side accelerated graphics for VDI applications.

[#] Wed May 13 2020 18:14:19 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


Java apps still don't support Wayland natively; they run via Xwayland. This doesn't look likely to change any time soon. Same goes for anything that hasn't yet been ported to gtk3 or whatever's the sufficiently-recent version of Qt.

I'm running gnome3 on ubuntu 20.04 on an ice lake laptop. One thing that's kinda interesting is that Wayland consumes far less memory in certain edge cases where there are a large number of windows open; this seems to relate to the buffer copying thaton the composite rendering path. The difference is like 9 gigs for the (somewhat rare) case I was looking at.

I'd run wayland all the time, but there are issues with annoying flickering of small popup windows in non-native apps (java stuff like dbeaver or intellij)

[#] Wed May 20 2020 13:54:16 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

Interestingly, one of the biggest pushes forward for Wayland might be ... Windows. Go figure.

Microso~1 just announced [ https://tinyurl.com/y7anuh45 ] that they're putting a Wayland compositor into WSL, that uses some sort of RDP hack to talk back to the desktop. As before, I'm still not sure what this offers over and above just running Linux in a VM on your own, but it's interesting.

When running Java apps, does the JRE link to the system Xlib or does it talk to the X server directly? One would think that a replacement Xlib that writes directly to the Wayland compositor would be more efficient than having to keep Xwayland around. Of course, X is such a convoluted mess that it would probably break things <shrug>

[#] Wed May 20 2020 14:49:11 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


don't forget that there are two different library implementations of the X wire protocol these days: Xlib, and libxcb. You're essentially talking about embedding Xwayland into the library so it runs in the same process and although it would be a bit more efficient, there are various issues that probably make it prohibitive.

Great, MS's RDP hack will surely be slower than the VMSVGA stuff that is already too slow.

All three GPU vendors offer their own GPU virtualization technology for direct rendering (requiring native drivers in the guest.) The issue is that each technology is only supported by one or two hypervisor vendors.

[#] Wed May 20 2020 18:20:37 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

All three GPU vendors offer their own GPU virtualization technology
for direct rendering (requiring native drivers in the guest.) The issue

is that each technology is only supported by one or two hypervisor

How do I find out which hypervisor does it on my machine? I have a Ryzen 5 3400G with RX Vega 11 graphics. Where can I go to find out what works on my machine? I'd love to have accelerated graphics on both operating systems, and I hate dual booting.

[#] Wed May 20 2020 20:52:30 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


looks like AMD's version is called MxGPU. It depends on SR-IOV, which I beieve requires BIOS support etc. Probably only for FirePro GPUs.

https://www.amd.com/en/graphics/workstation-virtualization-solutions-csp

[#] Thu May 21 2020 13:31:18 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

Ok, I've seen that. I think they intended it for VDI applications. I've got a big AMD cluster that we were going to do a VDI experimnent on, but someone snagged it for another project. My personal rig doesn't have IOV, unfortunately.
:(

[#] Thu May 21 2020 17:34:05 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


yeah, VDI applications and GPU compute virtualized hosting, most likely. server-class motherboard and pro-grade GPUs.

[#] Fri May 22 2020 15:46:12 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


so. many. bugs. in desktop linux lately. it's almost as if the kernel is being developed by a sprawling, worldwide community and no single person has a sufficient understanding of what they're modifying, so they keep playing whack-a-mole.


my $shrink_wrapped_os has been much less problematic

[#] Fri May 22 2020 21:18:36 UTC from darknetuser

[Reply] [ReplyQuoted] [Headers] [Print]

2020-05-22 11:46 from LoanShark

so. many. bugs. in desktop linux lately. it's almost as if the kernel

is being developed by a sprawling, worldwide community and no single
person has a sufficient understanding of what they're modifying, so
they keep playing whack-a-mole.


my $shrink_wrapped_os has been much less problematic



Yeah, pretty much. You need to go with extremely conservative distributions or migrate to a BSD if you want a sane experience nowadays.

[#] Fri May 22 2020 21:20:23 UTC from nonservator

[Reply] [ReplyQuoted] [Headers] [Print]

Having passed the point of Peak Desktop Linux, I've gone back to the previous state of affairs: Using Linux in text-only mode, and accessing it from a Windows desktop. It would be nice if there was something better, just like it would be nice if there was voice recognition software that I could trust not to phone home and sell me out to America-hating megacorps and the derp state. Out of all the alternatives, Haiku seems the only one with potential to become my new daily driver before I die.



[#] Sat May 23 2020 11:37:39 UTC from darknetuser

[Reply] [ReplyQuoted] [Headers] [Print]

2020-05-22 17:20 from nonservator
Having passed the point of Peak Desktop Linux, I've gone back to the
previous state of affairs: Using Linux in text-only mode, and
accessing it from a Windows desktop. It would be nice if there was
something better, just like it would be nice if there was voice
recognition software that I could trust not to phone home and sell me
out to America-hating megacorps and the derp state. Out of all the
alternatives, Haiku seems the only one with potential to become my
new daily driver before I die.


Why would you bet on Haiku over some other established operating system? Just curious.

[#] Sat May 23 2020 15:16:43 UTC from nonservator

[Reply] [ReplyQuoted] [Headers] [Print]

I'd bet on Haiku being a more usable alternative than the competition because of its lineage, historical progress, and current state of development. TempleOS would be great, but adding networking violates God's law. And Urbit would be a wonderful idea if it were actually built from the ground up instead of running as fifty million layers of inefficient abstraction on top of the same old fifty million layers of legacy crap.



[#] Sat May 23 2020 18:35:42 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

There are three reasons I still run my home desktop on Linux:

1. Nightly backup of my assets that are hosted in a data center, which runs using rsync+ssh with btrfs snapshots

2. The same machine does double duty as a NAS for the rest of the household.

3. Kdenlive. Say what you want but it's still my favorite video editor on any platform.

There is a Windows game I want to run, but gaming on Linux is teh crapola, and I don't have the patience to play with Wine for a week to get a game to run, and apparently I don't have the correct hardware for GPU virtualization. Do Windows games run properly (accelerated video) on Windows Server? I'd be more comfortable running a virtualized "always on" Linux workload on top of a server OS than on top of Windoze 10.

Honestly if someone would build a proper Type 1 *desktop* hypervisor, that could run multiple operating systems with accelerated video -- even if only one could have the screen at a time -- that would be the ideal situation.  For the time being, I'd also be ok with having to install a second video card for the guest OS and plugging that into a free input on my monitor.  I think that's possible?



[#] Sat May 23 2020 18:37:44 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

Having passed the point of Peak Desktop Linux, I've gone back to the previous state of affairs: Using Linux in text-only mode, and accessing it from a Windows desktop. 

That's more or less where I'd like to be as well, but as previously mentioned there is at least one Linux app that I refuse to abandon.

Are you running your text mode Linux in a virtual machine, on separate hardware, or using WSL?



[#] Sat May 23 2020 20:26:43 UTC from nonservator

[Reply] [ReplyQuoted] [Headers] [Print]

Ig - I've played around with virtualization over the years as it became less painful, but at the moment I'm back to running Linux on a separate machine. Though I do also run WSL, as I've found it's nice having a full Linux command line that's actually well integrated with the host instead of bolted on a la Cygwin. As far as distribution, the way Ubuntu is going I may soon have to start looking again into alternatives. Hearing good things about Nix and Alpine.



[#] Sat May 23 2020 20:29:49 UTC from nonservator

[Reply] [ReplyQuoted] [Headers] [Print]

Also, I am running a remote desktop from the Linux box, but it's just Openbox with a few extra tools like gmrun. Most of my time is spent in a tmux'd terminal, the remainder in a handful of different browsers with a very small Javascript whitelist.



[#] Sun May 24 2020 19:23:12 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]


WSL 1 is actually quite nice. The host integration is great and it's seamless to run. I ran it right up until I got to the point where I needed to run Docker, which doesn't work.

WSL 2 is little more than a VM, and if I'm going to run a VM, I might as well run real Linux.

My desktop rig at home is running Kubuntu (whatever the latest is). Although the Ubuntu experience improved greatly when they finally abandoned that awful Unity desktop, the look of KDE 5 finally brought me back home now that the KDE people have abandoned the "phone UI on a desktop" trend that some others are still pursuing, and they aren't part of the 2D-flatso trend. It works like an actual desktop, optimized for an upright screen with a keyboard and mouse. Imagine that.

[ https://blog.zerosector.io/2018/07/28/kvm-qemu-windows-10-gpu-passthrough/ ]

I have to figure out whether something like the above will work. I'll buy a dedicated video card for virtualized Windows if it will let me have the best of both worlds. My guess is that the hardware required for PCI passthrough to a guest would be far less bleeding-edge than the hardware required for GPU virtualization. I don't even need it to pass the video source back up to the host -- I'm more than happy to give it its own input on my monitor.

Go to page: First ... 56 57 58 59 [60] 61 62 63 64 ... Last