Yes, now it should be using CPU for rendering. If you're eager to save some cycles, you could recompile both Xorg and Mesa with optimizations "-flto=2 -march=native -O3 -pipe -fno-stack-protector -fno-semantic-interposition -fmerge-all-constants". That's one more of beauties of open source :) That said, I don't know how hard it might be on SuSe. On Archlinux here we have ᴬᵁᴿ repository, and building e.g. mesa from source is as easy as a command "yaourt -S mesa-git".
On 7 December 2017 at 18:36, Ewen Chan <chan.e...@gmail.com> wrote: > Hi-Angel: > > I'm just asking due to innate curiosity. > > But the other part of it is I am wondering if the other driver is using CPU > cycles to draw/render the display/(raster?). > > I am asking because in the analyis runs, they are taking longer to run than > they were before I blacklisted the mgag200 driver. (Granted it is still very > early in the entire script, but the early results would suggest that the > system might now be using the CPU to draw/render the screen (raster?) due to > the analysis runs now taking longer to complete (for each of the three out > of 16 runs that I have completed so far). > > Thanks. > > Sincerely, > Ewen > > On Thu, Dec 7, 2017 at 10:32 AM, Hi-Angel <hiangel...@gmail.com> wrote: >> >> Yeah, nice, it worked. As for what other driver in the output should >> accord to vesa or whatever that provides the basic functional of >> outputting to a monitor — sorry, I don't know, I hope somebody else >> here can tell it. I don't think it's important for our purposes >> though. >> >> On 7 December 2017 at 18:18, Ewen Chan <chan.e...@gmail.com> wrote: >> > Hi-Angel: >> > >> >> Have you rebuild initramfs after blacklisting by the way? >> > >> > So...I did what that thread (and the thread that it points to within >> > that >> > thread) says to do. >> > >> > Created blacklist.conf and then put in there: >> > >> > blacklist mgag200 >> > >> > and then I ran dracut --regenerate-all --force and rebooted (per the >> > thread-inside-that-thread's instructions). >> > >> > (like I said, I'm a grossly underqualified sysadmin so I just do what "I >> > am >> > told" from those sources.) >> > >> > >> > Here is the output of lsmod: >> > >> > Module Size Used by >> > ebtable_filter 12827 0 >> > ebtables 35009 1 ebtable_filter >> > ip6table_filter 12815 0 >> > ip6_tables 27025 1 ip6table_filter >> > iptable_filter 12810 0 >> > ip_tables 27239 1 iptable_filter >> > x_tables 34059 5 >> > ip6table_filter,ip_tables,iptable_filter,ebtables,ip6_tables >> > af_packet 39847 0 >> > fuse 95758 3 >> > iscsi_ibft 12862 0 >> > iscsi_boot_sysfs 16051 1 iscsi_ibft >> > raw 13091 0 >> > msr 12865 0 >> > joydev 17344 0 >> > iTCO_wdt 13480 0 >> > iTCO_vendor_support 13718 1 iTCO_wdt >> > dm_mod 110780 0 >> > intel_rapl 18783 0 >> > intel_powerclamp 14690 0 >> > coretemp 13435 0 >> > kvm_intel 151399 0 >> > kvm 496652 1 kvm_intel >> > crct10dif_pclmul 14307 0 >> > crc32_pclmul 13133 0 >> > crc32c_intel 22094 0 >> > pcspkr 12718 0 >> > sb_edac 26894 0 >> > edac_core 66438 1 sb_edac >> > igb 204492 0 >> > ptp 18933 1 igb >> > i2c_i801 22557 0 >> > pps_core 19333 1 ptp >> > ipmi_si 57482 0 >> > i2c_algo_bit 13413 1 igb >> > ipmi_msghandler 49676 1 ipmi_si >> > mei_me 18355 0 >> > wmi 19193 0 >> > mei 86782 1 mei_me >> > lpc_ich 21093 0 >> > ioatdma 71777 0 >> > mfd_core 13435 1 lpc_ich >> > shpchp 32951 0 >> > dca 15130 2 igb,ioatdma >> > processor 44678 0 >> > button 13971 0 >> > hid_generic 12559 0 >> > usbhid 52573 0 >> > btrfs 1022893 2 >> > xor 21411 1 btrfs >> > raid6_pq 101908 1 btrfs >> > sd_mod 50160 4 >> > ghash_clmulni_intel 13230 0 >> > aesni_intel 52860 0 >> > isci 149868 0 >> > aes_x86_64 17131 1 aesni_intel >> > glue_helper 13990 1 aesni_intel >> > lrw 13286 1 aesni_intel >> > gf128mul 14951 1 lrw >> > ablk_helper 13597 1 aesni_intel >> > cryptd 16263 3 >> > ghash_clmulni_intel,aesni_intel,ablk_helper >> > ehci_pci 12914 0 >> > libsas 87336 1 isci >> > ehci_hcd 79237 1 ehci_pci >> > ahci 29929 2 >> > scsi_transport_sas 45130 2 isci,libsas >> > libahci 36105 1 ahci >> > usbcore 254961 3 ehci_hcd,ehci_pci,usbhid >> > libata 244519 3 ahci,libahci,libsas >> > usb_common 13057 1 usbcore >> > sg 40629 0 >> > scsi_mod 244588 6 >> > sg,isci,scsi_transport_sas,libata,libsas,sd_mod >> > autofs4 42930 2 >> > >> > Out of that list, I don't see mgag200 there, but then again, I also >> > don't >> > see any module that I recognize as being a "video driver" either. >> > >> > I hope that helps answer your questions(? 0.o?) >> > >> > Thanks. >> > >> > Sincerely, >> > Ewen >> > >> > >> > On Thu, Dec 7, 2017 at 1:46 AM, Hi-Angel <hiangel...@gmail.com> wrote: >> >> >> >> Don't worry, I don't believe in Laplace's demon, and hence I believe >> >> everybody don't know something. >> >> >> >> Tbh I'm not sure if the output of lspci implies the module is still >> >> loaded, although I would assume it still is. Either way, to be sure >> >> you can use `lsmod` command, it lists all currently loaded modules. >> >> Have you rebuild initramfs after blacklisting by the way? >> >> >> >> On 7 December 2017 at 08:32, Ewen Chan <chan.e...@gmail.com> wrote: >> >> > Stupid question though (again, I'm a grossly underqualified >> >> > sysadmin). >> >> > >> >> > How can I tell if the blacklisting worked correctly? >> >> > >> >> > When I type in: >> >> > >> >> > # lspci -v | more >> >> > >> >> > this is what it outputs for the VGA section: >> >> > >> >> > 08:01.0 VGA compatible controller: Matrox Electronics Systems Ltd. >> >> > MGA >> >> > G200eW WPCM450 (rev 0a) (prog-if 00 [VGA controller]) >> >> > Subsystem: Super Micro Computer Inc Device 062f >> >> > Flags: bus master, medium devsel, latency 64, IRQ 11 >> >> > Memory at dd000000 (32-bit, prefetchable) [size=16M] >> >> > Memory at df800000 (32-bit, non-prefetchable) [size=16K] >> >> > Memory at df000000 (32-bit, non-prefetchable) [size=8M] >> >> > Expansion ROM at <unassigned> [disabled] >> >> > Capabilities: [dc] Power Management version 1 >> >> > Kernel modules: mgag200 >> >> > >> >> > Is there another way to confirm that the blacklisting did what it was >> >> > supposed to? >> >> > >> >> > Thanks. >> >> > >> >> > On Wed, Dec 6, 2017 at 11:39 PM, Hi-Angel <hiangel...@gmail.com> >> >> > wrote: >> >> >> >> >> >> On 7 December 2017 at 06:19, Hi-Angel <hiangel...@gmail.com> wrote: >> >> >> > On 7 December 2017 at 06:05, Ewen Chan <chan.e...@gmail.com> >> >> >> > wrote: >> >> >> >> Hi-Angel: >> >> >> >> >> >> >> >> Thank you for that!!! >> >> >> >> >> >> >> >> Two questions: >> >> >> >> >> >> >> >> 1) Will the commands from the CentOS distro work with SuSE? >> >> >> > >> >> >> > Well, the linked post doesn't show how to blacklist because it was >> >> >> > created after the fact (author forgot to re-build initramfs). For >> >> >> > an >> >> >> > example of doing that you can refer e.g. this >> >> >> > https://askubuntu.com/a/110343/266507 Except I am not sure how to >> >> >> > rebuild initramfs on SuSe — on Archlinux I'm using it is `sudo >> >> >> > mkinitcpio -p linux`. >> >> >> > >> >> >> >> 2) Do you think there will be problems using the VESA driver >> >> >> >> instead >> >> >> >> of >> >> >> >> the >> >> >> >> mgag200 driver? (i.e. the GUI/remote X/VNC would exhibit >> >> >> >> unexpected >> >> >> >> behaviours? >> >> >> > >> >> >> > Nothing that I know of. You'd obviously get a lower graphics >> >> >> > performance, but otherwise I think it should be fine. >> >> >> >> >> >> You know, btw, another silly idea: if blacklisting the driver will >> >> >> help, but you actually care of graphics performance — you could try >> >> >> enabling it back, and then installing modesetting driver, and >> >> >> forcing >> >> >> Xorg to use it through a xorg.conf. Per my understanding the leak >> >> >> could specifically be in Matrox DDX driver — if this is the case, by >> >> >> replacing it with modesetting DDX you'd keep the performance and get >> >> >> rid of leaks. "modesetting" is a vendor-neutral DDX driver which is >> >> >> implemented on top of whatever driver provides OpenGL functional. >> >> >> >> >> >> It should be noted though that if leaks are in the matrox's >> >> >> provision >> >> >> of OpenGL, it won't help. >> >> > >> >> > >> > >> > > > _______________________________________________ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s