Re: Centos laptop:: video cards

[ken <gebser@xxxxxxxxxxxx>]

On 10/05/2014 12:32 PM John R Pierce wrote:
> ....
> the DDR3 on a Intel i5-4570 (random upper midrange cpu I picked) has
> 25.6GB/sec memory bandwidth.  a typical 1920x1080 display is 2Mpixels,
> at 24 bit/pixel and 60Hz LCD refresh rate, thats 360MB/sec to refresh
> the display.  almost *nothing* compared with that 25GB/sec bandwidth.
> lost in the noise (half of the .6, to be more specific).

John and all,

This can be seen as a good approach in that it suggests the kind of 
rational approach to making an evaluation toward purchase.  But the 
example is a bit oversimplistic.

(I'll not provide links to the below because this information can be 
found in text- and other sorts of books on programming, especially those 
on video programming.)

The calculations John makes are valid as far as they go, valid for a 
screen with no applications/windows visible on it.  Every time a window 
is opened onscreen not only must that window be painted on, but what was 
behind that window must be preserved in memory (in the even that window 
is closed).  This applies to every window which is opened on that 
screen.  Considering that there are often windows on top of windows on 
top of windows, we can see that there are layers upon layers of screen 
data which must be saved in memory and recallable at the click of a 
mouse.  And not only must the screen data per se be stored in memory, 
but also its coordinates and "stack" position (which other windows 
and/or screen elements) it is "on top of" or "underneath".  There are 
many other window properties which must be saved and recalled and then 
deleted to/from/to memory at appropriate times.  (Consult a decent book 
on low-level X programming for some serious surprises.) Keeping track of 
all of this means that there is a lot of overhead in properly managing a 
display.

Don't forget the cursor: as it moves about the screen it, the screen 
underneath it (composed of different either wholly or partially 
displayed windows, all stored in different parts of memory) must be 
constantly saved and restored.  And for this to happen at all, the mouse 
must be constantly polled for input-- e.g., for movement, but also 
accompanying keyboard and mouse-button input-- and change shape 
accordingly.  The cursor also changes shape as it moves over parts of 
the screen with different properties, stored in different parts of 
memory, requiring management overhead to determine which ones.

Moreover, things happen within windows.  Text might be updated, images 
changing, and videos running, even in windows not currently having the 
focus.  Every time the user clicks on a dropdown or opens a child window 
within an application or cuts/copies and/or pastes text, screen data 
must be saved and managed.  Apps like Firefox and Thunderbird, moreover, 
can have tabs, each of which is yet more screen data to store and manage.

Now consider that with X we can have multiple viewports, what you might 
think of as desktops.  The number of these is configurable, but I've 
often configured my display for four of them.  (A long time ago I read 
that X was capable of handling 4 billion of them, at the time I though, 
"Pretty cool... more than one for each person on the planet".)  Each of 
those can contain/entail everything mentioned above for a single 
viewport/desktop, possibly multiplying memory usage and processing by a 
factor of four.  Lay on top of all of this that some people run virtual 
machines which can increase the need for video memory by yet another factor.

In brief, a lot has to happen in addition to the simple rastorization of 
the screen that John describes, and so a video subsystem requires many 
times the amount of memory he suggests and number of discrete processor 
instructions his description would imply.  Unless-- as could be the 
case-- there is some utility to assess/monitor all of these factors and 
output meaningful numbers, numbers which could be compared against 
similarly meaningful assessments/benchmarks of available video cards, 
we're left with anecdotal evidence which can vary widely from one user 
to another, for the same user from one day to another, even from one 
session to another.  In addition, what a user does on his current system 
might not be the same as what he hopes to do or unexpectedly ends up 
doing on his next system, the system he's looking to purchase.  Examples 
of anecdotal evidence might include: the user moves a window and, 
instead of the screen underneath it being instantly repainted as the 
window moves along, a gray trail is left in the wake of the window which 
may take some seconds to be filled in; or switching to an existing but 
hidden window (hidden under other windows), it takes a bit of time for 
the contents of that window to be painted in; a window initially resists 
moving after the user has grabbed it with the mouse pointer.  These are 
all symptoms of a slow video subsystem; there are others, both more 
trivial and more serious-- and the sort of behavior I would think most 
users would want to avoid.  Question (one among several): Wouldn't this 
kind of behavior be more likely to happen under a heavy system load-- 
say, upwards from 4.0 and even above 6.0-- when dedicated video hardware 
is lacking?
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos