lkml.org 
[lkml]   [1998]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: GGI, EGCS/PGCC, Kernel source

On Wed, 25 Feb 1998, Nathan Uno wrote:

> >> No, that would be "Some people have valid objections to the current state
> >> of ggi without knowing what is being worked on in the project :)"
> >
> > IMHO, GGI still has no strong concepts to support accelerated operations
> > on PC GX cards. [...]
>
> Define "strong concept". [...]

not something like this:

- ioctl() [... sloooow]
- page fault [... sloooow]
- soft-queueing of GX commands [... latency problem]

i did not say it can not be done, i just say that it's at least 70% of the
really hard work. And the attitude was always 'acceleration? ah, we'll do
that on another afternoon as well'.


> I lurk on the GGI mailing list, and this is a
> hot topic of discussion. Several drivers already do accelerated
> operations on their PC GFX cards.

yes, for millisec-latency tasks like clearing the whole screen. Just to
mention one huge problem, on a considerable percentage of current PC
cards, it is lethal to access the framebuffer from the CPU side, and let
the accelerator chip access it too from the video card side. Virge cards
last i remember corrupt random areas of the frame buffer in such cases.
GGI currently lets users map the framebuffer.

> Have you *tried* GGI? We have GGI Descent, many GGI demos, etc. Once
> you've tried it, you can comment on whether or not the speed is sane.

i have tried XGGI, and it's kinda slow.

-- mingo


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.186 / U:0.952 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site