Re: [linux-fbdev] New api again

[Sven L. <lu...@dp...>]

On Thu, Jan 18, 2001 at 04:31:36PM -0800, James Simmons wrote:
> 
> > what if i wanted to write a fbdev for, for example, the 3Dlabs Oxygen GVX420
> > board ? 
> > 
> > For you information this board contains 3 different chip, A gamma 2 chip,
> > acting as agp bridge and T&L engine, and 2 Permedia4 chips, doing 3D setup and
> > rasterization. They can be configuredto be shared for rasterizing the same
> > framebuffer, splitting the scanline between them, or to support dual head.
> 
> I assume T&L is texture and lighting engine. 

Yes, that and some other stuff, i cannot say more though.

> > Each Pm4 has one pipeline, i think.
> 
> First a pipeline is a collect of pipes. Each pipe takes data and changes
> it a certain way. This occurs until we reach the end of the pipeline when
> we get the final desired rastered image.

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

> 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.

> would be say a triangle strip was passed to the the first chip to say be
> rotated. Then that data is passed onto the second chip to be tranformed to

No, rotate is done by the gamma.

> give the appearance of a prespective view. In this case their is one

mmm, i can have stereoscopic view from one pm4. I guess you can also have two
identic copies of the image in both pm4, each rendering to one output. not
sure though.

> pipeline with 2 pipes. Now if this doesn't occur and each chip processes
> data independent of each other then their is two pipelines with one pipe

I think what trully happens is that it can be configured as only one pipe, or
as two independent pipes, isn't it ?

> each. This is of course assuming each GPU, the Pm4's, can't handle more
> than one graphics command at a time. Is the T&L shared between both

Not true, they can have more than one framebuffer (upto 4 i think). 

> GPU's. I really have to look at the hardware specs to say exactly. As you
> can see for a mor advance card like the Oxygen things get more a bit more
> complex. 

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

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

I may be writting a fbdev for the appian J2000 (two pm3 and 1 gamma, the pm3
cannot be shared for 1 display though, only in dual head, but the gamma can
provide 3D Accel for both display).

> > The additional problem, is that you can address the rasterizer chip either
> > directly (they have FB and Command register pci aperture, and a separate pci
> > id) or trough the Gamma chip, for example, for when doing 3D, you send command
> > to the gamma, which process them (T&L) and then forward the low level commands
> > to one or both Permedia4 chip. If you want ot use one or both accesses, you
> > would need to synchronize correctly between them.
> 
> Okay I'm taking a shot in the dark since I don't have the specs but I'm 
> assuming the Gamma chip is for DMA, especially since you mentioned that 
> it manages the agp port, and the Command register space is for MMIO

mmm, ...

To share some light on the circunstances, i am doing the Xfree driver for it.

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).

> programming. Yes you do you have to manage access to both of them. 

I have access to both type of command with both type of chips.

> Internal to the fbdev driver this is pretty simple. When userland wants to
> play around with this stuff then you need a RRM (rendering resource
> manager) to balance access. As 2.4.X stands right now you can't use the 
> DMA with fbcon but I will be working on this problem right now. 

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.

Friendly,

Sven Luther