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
