Return to BSD News archive
Xref: sserve comp.os.386bsd.apps:1006 comp.os.linux.misc:10725 Newsgroups: comp.os.386bsd.apps,comp.os.linux.misc Path: sserve!newshost.anu.edu.au!munnari.oz.au!foxhound.dsto.gov.au!fang.dsto.gov.au!yoyo.aarnet.edu.au!news.adelaide.edu.au!news.cs.su.oz.au!harbinger.cc.monash.edu.au!msuinfo!agate!library.ucla.edu!csulb.edu!csus.edu!netcom.com!hasty From: hasty@netcom.com (Amancio Hasty Jr) Subject: Re: DOOM for X Message-ID: <hastyCMJL20.Mr4@netcom.com> Organization: Netcom Online Communications Services (408-241-9760 login: guest) References: <2lm9ih$6s5@godot.cc.duq.edu> <glen.763349922@paladine> <markus.57.00E736E9@rsvl.unisys.com> Date: Sat, 12 Mar 1994 08:03:35 GMT Lines: 77 In article <markus.57.00E736E9@rsvl.unisys.com> markus@rsvl.unisys.com (Mark K Vallevand) writes: >In article <glen.763349922@paladine> glen@paladine.ece.jcu.edu.au (Glen Harris) writes: > >>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....... > >No, no, no. The X shared memory extension simply gives the X app and X server >shared access to a piece of memory so that they can exchange data quickly. >Instead of sending a huge message through, a tiny message is sent with a >reference to the shared memory that has the huge chunk of data. It's not >exactly as it is in DOS. Its not that close to what it is in DOS. The above is correct. Well, at least with the S3 801/928,864 we can map the entire cards video memory into a user space. Linux (whatever version is at ) can can do this --- if memory does not fail me XFree86 for linux does this. There was a limitation on FreeBSD which prevented us from mapping the entire S3's memory. With the latest release of FreeBSD we should be able to do it also. It should be interesting to find out if we can make the X server's video memory shared with a clients space so that an application can read or write as fast as it can to the card. In essence take complete control of the card just like in DOS. Well not quite because there is the matter of vga commands or s3 graphic commands to the card that one can't issue from the client unless one gets ioperm and if one keeps going on this direction there is no need for the server because one duplicates the server code. Lets called this morphing code :) A different but related solution to the above problem. When I used to work for touch communications, we implemented a terminal server for our OSI stack. -- The OSI stack was one of those client-server models;however, the architects had a good enough sense to also specify an api for each level of the osi stack. So our terminal server became part of our OSI stack residing at the tranport layer level. With very little effort I also merged our FTAM server (file server stuff) to our stack to just measure the performance impact of our IPC mechanism. It was a lot in our case because we used ASN.1 encoding... This is not to say that X's IPC is a high overhead rather that one can have a server which also has clients in the same process space. Okay, I will get off my soap box. The ideal situation for us is if the so called X server could also provide an interface so we can access the server's low level graphic functions an exploit the underlying graphic hardware. Or forget about X and standardize on a graphic library for graphically demanding applications. BTW: sgi took the approach of both X and access to the low level graphics. So an app is capable of accessing the low level graphic hardware at a very fast speed, while X is well doing slowly its own thing. Hope this inspires someone out there, Amancio -- FREE unix, gcc, tcp/ip, X, open-look, interviews, tcl/tk, MIME, midi, sound at freebsd.cdrom.com:/pub/FreeBSD Amancio Hasty, Consultant | Home: (415) 495-3046 | e-mail hasty@netcom.com | ftp-site depository of all my work: ahasty@cisco.com | sunvis.rtpnc.epa.gov:/pub/386bsd/X