On Tuesday 08 January 2002 04:12 pm, Leif Delgass and Manuel Teira wrote:

> Happy New Year!

Hopefully for all, it will be a better one than the last...

> > Well, after the holidays, I would like to recover the development in the
> > mach64 branch. I started today to investigate the DMA stuff because I
> > think that perhaps Frank is very busy and he has no time to do this work.
> > The DMA problem was discovered aprox. Oct 21th and we have no news about
> > any progress in  DMA. I'm sure  that Frank would do it better than me,
> > but I can try.

I've had starts and stops.  However, I am still working on things and have 
been with what time I've actually had that I could think straight on and I'm 
pretty close to having something- sorry about the delays on my part, I KNOW 
you're all chomping at the bit, I am wanting this to happen as much as you 
all are.

> It sounded like Frank had written some code already (he mentioned being
> "halfway done" in early December).  Frank, is your work in a state that
> could be commited to the branch so others could help finish it?  If so,
> this might be a good place to start a new branch tag since we currently
> have a "working" driver.  Before long we'll also need to merge in changes
> from the trunk, since 4.2.0 seems close to release.

I'm about ready to actually make that branch- I nearly have the code in place 
(You'd not believe the fun stuff that has conspired against me to finish the 
code...  Job hunting, "honey do" projects, my father being ill- I couldn't 
get focused long enough to sit down and plug the code in...  But enough of 
that, it's in the past.) and I'm planning on getting it completed sometime 
this upcoming week and start verifying that I've not broken anything.  I'll 
go ahead and make a branch at that point in time.

> > I've been looking at the r128 freelist implementation, so I've derived
> > that the register called R128_LAST_DISPATCH_REG (actually
> > R128_GUI_SCRATCH_REG1) is used to store the age of the last discarded
> > buffer. So, the
> > r128_freelist_get is able to wait for a discarded buffer if there's no
> > free buffer available.
> >
> > Could this be made in the mach64 driver, say with MACH64_SCRATCH_REG1 ?
> > In my register reference it says that these registers can be for
> > exchanging information between the BIOS and card drivers, so, is sane to
> > use them for this task?
>
> I'm not sure that that would be safe to use.  According to r128_reg.h, the
> r128 has BIOS scratch registers and GUI scratch registers, where the
> mach64 has only the scratch registers used by the BIOS.  The mach64
> Programmer's Guide says that SCRATCH_REG1 is used to store the ROM
> segment location and installed mode information and should only be used
> by the BIOS or a driver to get the ROM segment location for calling ROM
> service routines.

Hm...  I've been wondering why they used a scratch register when the private 
area's available and could hold the data as well as anything else.  Anybody 
care to comment?  As it stands, I've got the info being placed in the private 
data area as a variable.

> > I've also seen that there's no r128_freelist_put (it's present in mga
> > driver, for example). Isn't it necessary?

Depends.  I'm not sure how I'm going to code things.  I've got to account for 
clients holding onto or discarding their buffers upon submission (As well as 
burning them off because they're shutting down) in the DRM and I'm working on 
this part (The actual DMA submission part's fairly easy, but the trappings 
within the DRM are a different story.) right now.  My thinking is that if 
it's a discard, we push it back into the freelist and view it as unavailable 
unless the age is past the timeout point.

> > And, when is a buffer supposed to be discarded. Is this situation
> > produced in the client side?

It appears to be a client side behavior.  The way that most of the cards seem 
to do their DMA is they queue up the buffer in question with an ioctl such as 
DRM_IOCTL_R128_VERTEX, using a struct not unlike this for parameters for the 
ioctl:

typedef struct drm_r128_vertex {
        int prim;
        int idx;                        /* Index of vertex buffer */
        int count;              /* Number of vertices in buffer */
        int discard;            /* Client finished with buffer? */
} drm_r128_vertex_t;

idx is the value pulled from the value in drm_buf_t.  I'll admit that prim's 
still a little foggy to me, but count is obvious as is discard.  Basically 
the client tells the DRM to put it back into the freelist because it's done 
with it.  I would think that there is a tradeoff for holding onto versus 
releasing buffers- holding onto them would be a speed boost, but at the 
expense of limiting how many clients had buffers.  128k's not a lot of buffer 
space- it doesn't allow for many verticies, etc. so I'd wonder what kind of 
benefit a client would derive from holding onto the buffer for things like 
verticies.  Textures might be an advantage, but again, you're stealing things 
from other potential clients when you do that.

While we're discussing things here, can anyone tell me why things like the 
emit state code is in the DRM instead of in the Mesa drivers?  It looks like 
it could just as easily be in the Mesa driver at least in the case of the 
RagePRO code- is there a good reason why it's in the DRM?

-- 
Frank Earl

_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to