Re: [linux-fbdev] New api again

[James S. <jsi...@su...>]

> Ok, i understand this. each pipe can also be called unit, isn't it ?

Yes. I also have heard it called a stage.

> > Well that depends. Can data be processed by one Pm4 chip and then passed
> > to the second Pm4 chip to be processed by another stage? A good example
> 
> No, but they can handle part of the same image, or process the exact same
> image doubly.

Don't think image. Think vertice object passed into the accel engine to 
be operated on. Rastering the image is just the last stage of the pipeline
that translates for processed vertice data into pixel image on screen.

> No, rotate is done by the gamma.
[snip]...

Okay. That was just for a example.

> You will need an NDA to get access to the specs though :(((

I plan to get around to this card eventually. 

> But i thought that as long as you are planing a new API, it may as well take
> this kind of cases into acount.

That is why I though about this approach.

> You are wrong, both the gamma and the permedia chips can do DMA (with kernel
> or DRI help), command MMIO (register writing) or direct fifo access (well you
> send pairs of register address and command data down the pipeline, sort of
> busy dma-like behavior without a dma engine).

Okay. Now I have a good understanding of what is going on. Most higher end
cards have a dual pipeline line approach. One for 2D stuff and one for 3D
stuff. The reason it is done this way is because the 3D stuff can take a
long time to process when compared to the 2D stuff. This would make the
X server very non responsive. With a dual pipeline approach you can a 
a independent pipeline that handles 2D so the X server is still snappy
while still processing 3D stuff for different OpenGL clients. 

> My problem, is that you will have to be synchronizing in a way that is common
> between fbdev/whatever and X. under X i am planning to do 2D access directly
> to the rasterizer chip, but use the gamma for DRI/3D.

For 2.5.X I plan to have it such that when you open /dev/fb that fbcon
shuts down (replaced by dummycon). This way fbcon and DRI or whatever
don't step on each others feet.