[ Dropping x...@freedesktop.org from Cc, one copy of each list post is
enough :) ]
On 2017-12-07 05:39 AM, Hi-Angel wrote:
>
> 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 i
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 t
Felix:
I might be able to try that.
It'll probably be the better part of a week before I will get around to
testing that (only because my analysis script need to load the system
significantly enough in order to trigger this issue).
In regards to your question at the end, someone else who is more
P.S.
I'm neither a dev nor all that familiar with this stuff either.
I'm just a user. And I've been on the SuSE forums talking with those people
in trying to figure out this issue that I am seeing where Xorg was
consuming ~100 GiB of RAM which, pretty much every technical person I've
talked to so
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
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 drive
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
Hi-Angel:
> Yes, now it should be using CPU for rendering.
Hmmm...I am not so sure if that was really what I want.
It just reminds me of the adage of where you fix a leak/problem at one
part/section of a pipe, but then create another one problem somewhere else
down the pipe.
> That's one more o
Ewen Chan composed on 2017-12-07 11:22 (UTC-0500):...
> My early subjective analysis (with this mgag200 blacklist) puts the time it
> takes to run the simulations now on par with Windows and Windows just
> worked (properly) like this from the get go.
> People keep talking about great and wonderfu
On Thu, Dec 07, 2017 at 11:22:30AM -0500, Ewen Chan wrote:
> Hi-Angel:
>
> > Yes, now it should be using CPU for rendering.
>
> Hmmm...I am not so sure if that was really what I want.
>
> It just reminds me of the adage of where you fix a leak/problem at one
> part/section of a pipe, but then cr
-- Forwarded message --
From: Hi-Angel
Date: 7 December 2017 at 21:12
Subject: Re: X is consuming ~100 GiB of RAM(!)
To: Ewen Chan
On 7 December 2017 at 19:22, Ewen Chan wrote:
>> That's one more of beauties of open source
>
> The thing that I can think of that would be even mo
> It's been uncommon to have such a configuration AFAIK, frankly I was a
little
surprised to see someone mentioning some modern G200 use case.
Supermicro servers uses the Nuvoton WPCM450 BMC and it is off of that where
the Matrox G200eW resides (for the console/video output/display). (The
manual f
12 matches
Mail list logo
