riscy
[Top] [All Lists]

Re: Things ...

To: tor@tss.no
Subject: Re: Things ...
From: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au>
Date: 28 Jun 1993 19:36:44 +0800
Cc: riscy@pyramid.com
(Tor, this message is not specifically targetted at you, I'm just getting 
a little exasperated. Please don't take anything personally.)

>on the 34010 in 1024x768x1 (or x4), and it's slower than a 486+et4000 for
>almost anything.  The only thing that is slower on the PC is scrolling.
>The TDV 6230 is certainly much slower than a 486 + S3.

Am I talking to a brick wall? I _KNOW_ the 34k is slower - I thought 
I made that plain. If you can come up with a design that costs the same 
amount and gives better performance, go right ahead: I'm not hooked on the 
idea of using the 34010.

>Of course, the X-response on the PC gets real bad when compiling the
>kernel at the same time! :-)

I think that this is one small advantage of the "separate processor" 
approach, but not the most important for our particular application. 
Further on this point, I think that people will complain less about 
"graphics performance" when the main CPU is still free to run programs. 
The "two processor" approach should also make the machine more appealing to 
people who want to use the box as a server because users on the console 
will have less impact on the system performance. I suspect that most 
programs would run quite acceptably on the 34k - perhaps not benchmarking 
as fast as a dumb framebuffer solution, but certainly fast enough to be 
useful.

Side note: For those people who do use systems with 34010's, where 
exactly are the performance problems? Do you actually see the chip 
"painting" the screen, or is it just a general sluggishness? I suspect some 
of the performance problems could actually be due to the fact that X 
terminals are usually diskless, and the I/O overhead dominates the actual 
graphics performance. This would not be an issue with a "local" 
implementation.

People: _PLEASE_, if you can come up with a practical alternative for a 
video system (I know you're out there Steve <grin>), speak up now. It 
_would_ be much better to use a dumb framebuffer attached to the CPU, but I 
fear that the extra logic required to generate monitor signals and clock 
the data out of the VRAM at the right speed would be a 

To try and summarize my opinion, I'd just like to say that most programs 
(that I deal with) are not limited by the speed of the X server. Usually, 
the limitations are on the system I/O performance. I think that using a 
separate CPU to do graphics will make our system less complex (ie: cheaper) 
while still providing perfectly acceptable graphics performance. Not only 
that, but it makes the system a bit more "interesting", from a hobbiest's 
perspective (I mean, what's the point of doing it if it's not going to be 
interesting <grin>). If someone comes up with a cheap and simple 
alternative to the 34k solution, I'd be very happy to use it, but so far,
no one has, and the 34k is the best choice in my mind.

As for the guy that said he'd be willing to pay $1200 for the system, I 
can't agree. In my mind, once you get over the US$800 mark, you'll be much 
better off with a fully "commercial" system. As Neil mentioned before: if 
all you want is a faster PC, by all means, go and buy one. I know it looks 
like I'm harping on the point, but the price and complexity of this system 
are the factors which will decide its fate.

Again, I hope we've seen the end of the integer vs FP argument: that can be 
sorted out when the time comes. It's much more important to fill in the 
other parts of the system right now. Please don't bring it up again.

[...At the risk of repeating myself (again): If you're going to "knock" the 
34k solution, please make sure you have a viable alternative...]

Pat -- "There's only one thing left to do Mama, I got to ding a ding dang
        my dang a long ling long" (Jesus Built My Hotrod -- Ministry)
GCS d* -p+ c++ l++ m--- s+/- !g w- t- r

 

<Prev in Thread] Current Thread [Next in Thread>