*BSD News Article 28304


Return to BSD News archive

Xref: sserve comp.os.386bsd.apps:1008 comp.os.linux.misc:10738
Path: sserve!newshost.anu.edu.au!munnari.oz.au!ihnp4.ucsd.edu!agate!howland.reston.ans.net!math.ohio-state.edu!cyber2.cyberstore.ca!nwnexus!ole!rwing!eskimo!orestz
From: orestz@eskimo.com (Orest Zborowski)
Newsgroups: comp.os.386bsd.apps,comp.os.linux.misc
Subject: Re: DOOM for X
Message-ID: <CMHpoL.F75@eskimo.com>
Date: 11 Mar 94 07:48:10 GMT
References: <1994Mar3.131137.27311@infodev.cam.ac.uk> <CM44Lq.78x@seagoon.newcastle.edu.au> <2lkpg5$8hn@Tut.MsState.Edu> <hastyCMEw58.FMr@netcom.com> <2lm9ih$6s5@godot.cc.duq.edu> <glen.763349922@paladine>
Followup-To: comp.os.386bsd.apps,comp.os.linux.misc
Organization: Eskimo North (206) For-Ever
Lines: 35
X-Newsreader: TIN [version 1.2 PL2]

Glen Harris (glen@paladine.ece.jcu.edu.au) wrote:
: In <2lm9ih$6s5@godot.cc.duq.edu> mcquill@next.duq.edu (Tod McQuillin) writes:
: >Amancio, what effect, if any, do you think the shared memory extentions of X
: >have on graphics performance?

:   What it means is that a bitmap in memory is mapped directly over the
: screen, so an access to the array is an access to the screen.  After the
: mapping is set up, there's no calls to X for the graphics.  In effect,
: it's exactly as if you were in dos, but there's no 64Kb segment switching
: as the system does this transparently.  *I* don't know how page flipping 
: is done, maybe there's a X call to do this, or a fast memcpy during the
: refresh?  Inquiring minds.......

This isn't exactly correct. The MIT_SHM extension allows the client and
the server to share the memory associated with an XImage or Pixmap. This
means there is no need to communicate the bits between the server and
client. The server will use this Pixmap (the XImage gets turned into
a Pixmap in the server) as a source, as if a normal XImage had been
created. The savings can be enormous, as you can tell from running
mpeg_play with and without shared memory support.

This doesn't mean that server video memory is mapped into the client's
address space. That wouldn't make much sense, as the client would have
to know as much about manipulating the video board as the server does,
and in XFree86 this knowledge is substantial. That's the tradeoff: by
providing a unified API, the client can take advantage of a variety
of hardware, but at a cost of implementing this API by the server.

By cleverly taking advantage of shared memory to reduce net traffic,
and other properties of client/server relationships, the client program
can be more effective than if in control over everything, if only in
terms of complexity. But you can never get the same performance as
with dedicated systems that manipulate video boards directly.

-orest