Announcement

Collapse
No announcement yet.

Nouveau Still Pushing Forward In 2020 Thanks To Red Hat But Community Developers Leaving

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Microred
    replied
    Thanks to Red hat, from 5.6, my GTX 1050 TI and RTX 2080 TI will not work with nouveau unless a firmware blob is load by kernel.

    Linux user : "Let's be nice with Redhat and let's load some blob to make those GPU work nicely with their open source drivers :"

    kern.log:Apr 8 08:03:19 localhost kernel: [ 75.266362] nvkm_vmm_iter.constprop.0+0x362/0x7e0 [nouveau]
    kern.log:Apr 8 08:03:19 localhost kernel: [ 75.266377] ? nvkm_vmm_map_choose+0x80/0x80 [nouveau]
    kern.log:Apr 8 08:03:19 localhost kernel: [ 75.266393] ? gf100_vmm_invalidate_pdb+0x30/0x30 [nouveau]
    kern.log:Apr 8 08:03:19 localhost kernel: [ 75.266408] nvkm_vmm_ptes_unmap_put+0x4e/0x70 [nouveau]
    kern.log:Apr 8 08:03:19 localhost kernel: [ 75.266423] ? nvkm_vmm_map_choose+0x80/0x80 [nouveau]
    kern.log:Apr 8 08:03:19 localhost kernel: [ 75.266438] ? gf100_vmm_invalidate_pdb+0x30/0x30 [nouveau]
    kern.log:Apr 8 08:03:19 localhost kernel: [ 75.266453] nvkm_vmm_put_locked+0x1c5/0x210 [nouveau]
    kern.log:Apr 8 08:03:19 localhost kernel: [ 75.266467] nvkm_vmm_put+0x2b/0x50 [nouveau]
    kern.log:Apr 8 08:03:19 localhost kernel: [ 75.266482] nv50_instobj_dtor+0xa4/0xe0 [nouveau]
    kern.log:Apr 8 08:03:19 localhost kernel: [ 75.266489] nvkm_memory_unref+0x42/0x60 [nouveau]
    kern.log:Apr 8 08:03:19 localhost kernel: [ 75.266504] nvkm_mmu_ptc_put+0x103/0x170 [nouveau]
    kern.log:Apr 8 08:03:19 localhost kernel: [ 75.266519] nvkm_vmm_unref+0x172/0x1c0 [nouveau]
    kern.log:Apr 8 08:03:19 localhost kernel: [ 75.266534] nvkm_uvmm_dtor+0xf/0x20 [nouveau]
    kern.log:Apr 8 08:03:19 localhost kernel: [ 75.266543] nvkm_object_dtor+0xb3/0x100 [nouveau]
    kern.log:Apr 8 08:03:19 localhost kernel: [ 75.266551] nvkm_object_del+0x1c/0x80 [nouveau]
    kern.log:Apr 8 08:03:19 localhost kernel: [ 75.266559] nvkm_ioctl_del+0x33/0x50 [nouveau]
    kern.log:Apr 8 08:03:19 localhost kernel: [ 75.266567] nvkm_ioctl+0xe2/0x180 [nouveau]
    kern.log:Apr 8 08:03:19 localhost kernel: [ 75.266574] nvif_object_fini+0x57/0x80 [nouveau]
    kern.log:Apr 8 08:03:19 localhost kernel: [ 75.266589] nouveau_vmm_fini+0xd/0x20 [nouveau]
    kern.log:Apr 8 08:03:19 localhost kernel: [ 75.266603] nouveau_cli_fini+0x43/0x90 [nouveau]
    kern.log:Apr 8 08:03:19 localhost kernel: [ 75.266617] nouveau_drm_postclose+0x9f/0xd0 [nouveau]

    Linux user : "Ho damn, hard to debug when blob are involved, how can I fix it ?"

    RedHat dev : "Don't panic ! You can subscribe to Red Hat pro"

    Thanks them if you want, but do not bind Redhat with opensource.

    RedHat dev : "No it is not in our agenda to work with the opensource community"


    Leave a comment:


  • DanL
    replied
    Originally posted by mulenmar View Post
    Yeah, the guides didn't mention that package or command.
    And lay off the snark, you're bad at it. Two words don't a "riding the Caps Lock" make.
    *Shrug* Caps Lock offends my eyes when I'm skimming/speedreading.

    Leave a comment:


  • mulenmar
    replied
    Originally posted by DanL View Post

    Since when did this become magic?:
    Code:
    apt-get install nvidia-kernel-dkms


    See above (and lay off the Caps Lock).
    Yeah, the guides didn't mention that package or command.

    And lay off the snark, you're bad at it. Two words don't a "riding the Caps Lock" make.

    Leave a comment:


  • rmoog
    replied
    Originally posted by ix900 View Post
    I feel that the proprietary driver should be used by default on installation.
    This is demonstrably wrong! Can you even begin to imagine what kind of legal issues this creates? The binary nVidia driver is released under nVidia's EULA and therefore it is not compliant with the rest of the system from a distrubutor's POV. Canonical and RedHat would have to put up EULA acceptance forms before letting users download images of their distros. Failure to comply with this requirement would result in legal action from nVidia.

    Leave a comment:


  • brad0
    replied
    Originally posted by NotMine999 View Post
    Nor do you need to post how incompetent you are at getting something to work on Linux that "basically works out of the box".
    I feel bad for how mentally retarded you are.

    Leave a comment:


  • NotMine999
    replied
    Originally posted by brad0 View Post

    You don't have to advertise to people that you are willfully ignorant and stupid.
    Nor do you need to post how incompetent you are at getting something to work on Linux that "basically works out of the box".

    Leave a comment:


  • rogerx
    replied
    Originally posted by Tomin View Post
    Yeah, I've even used that same RX 460 a little while on a motherboard that has old fashioned BIOS so it should work without issues on Linux. To be exact I had GPT partioning although I didn't have UEFI (BIOS will read the bootloader from MBR just fine). It's also a combination that wouldn't work with Windows.
    The MSI RX460 2G is the piece of hardware purchased here. Probably a nice graphics card, just isn't nice to find-out about the non-compatbility with MBR, requiring EFI booting.

    Leave a comment:


  • Tomin
    replied
    Originally posted by rogerx View Post

    Yes really. The default/OEM AMD video card Windows 10 drivers typically require EFI/UEFI firmware booting and the drivers will fail properly loading/installing/working with MBR booted Windows 10. Obviously more than a slight oversight on system requirement specifications. (The AMD card recently purchased then tossed in a bin, was designed for Windows 7 era.)
    So, it was with Windows drivers. That explains it. I don't use Windows on my newer computers anymore.

    Originally posted by rogerx View Post
    However if I'm not mistaken, should be likely no problems as you likely experiece, if using the open source or Linux drivers while booting into Linux via MBR partitions.
    Yeah, I've even used that same RX 460 a little while on a motherboard that has old fashioned BIOS so it should work without issues on Linux. To be exact I had GPT partioning although I didn't have UEFI (BIOS will read the bootloader from MBR just fine). It's also a combination that wouldn't work with Windows.

    Leave a comment:


  • rogerx
    replied
    Originally posted by Tomin View Post

    Really? Which driver? I really doubt this because it seems to make little sense and also that I used to have CSM boot on my desktop until I converted it and it was using RX 460 at the time.
    Yes really. The default/OEM AMD video card Windows 10 drivers typically require EFI/UEFI firmware booting and the drivers will fail properly loading/installing/working with MBR booted Windows 10. Obviously more than a slight oversight on system requirement specifications. (The AMD card recently purchased then tossed in a bin, was designed for Windows 7 era.)

    However if I'm not mistaken, should be likely no problems as you likely experiece, if using the open source or Linux drivers while booting into Linux via MBR partitions.

    I think the Nouveau driver also inhibits signs of this problem as well, requiring to be loaded early on within the Linux boot stage versus loading nouveau module after system boot. Deals with the initialization process. Personally, I prefer booting via text, then enabling higher resolution once my operating system is successfully booted. I hate diagnosing boot bugs, and finding most boot bugs relating towards the features of having pretty higher resolution graphics! Boot me to text first, so I can check my Email and browse the Internet with mut & elinks, otherwise I'm sunk requiring a second computer for troubleshooting.

    But as I iterated, a slight stumbling block, and would *imagine* EFI being stable or having a fallback by the time I jump into EFI.
    Last edited by rogerx; 02-03-2020, 11:49 AM.

    Leave a comment:


  • Zan Lynx
    replied
    Originally posted by mulenmar View Post

    This is factually wrong. Modern versions of Windows include drivers for GPUs, beyond basic VESA support, so that their overdone 3D and transparency effects GUI doesn't make the OS look bad. These drivers are very basic, and in some cases I recall don't include OpenGL support (just DirectX), in addition to being out of date by installation time... but they exist.



    ...uh, you do realize that terminals not "accelerated" whatsoever by GPUs?
    Hmm, "...overdone 3D and transparency effects GUI..." I've run Windows 10 in VMs under QEMU-KVM many times. The virtual video card there does not support any 3D acceleration and yet Windows still performs well and does not look ugly. Windows doesn't need anything beyond VGA / VESA to work well. That's also true of its Safe Mode boot, which doesn't use GPU drivers.

    Terminals being accelerated is an interesting thing. Terminal text acceleration has been a thing for so long that people forget it's even there, but it definitely is. The original video cards had that as their whole job. They had font character data and as they read the video RAM that held the characters they would copy the font pixels into the video raster output.

    That's definitely acceleration.

    Leave a comment:

Working...
X