On Sat, 13 Oct 2001, Keith Whitwell wrote:
> On Sat, 13 Oct 2001 17:32, [EMAIL PROTECTED] wrote:
> > On Sat, 13 Oct 2001, Keith Whitwell wrote:
> > > > That's what I am trying to do. With not much luck so far. The reason
> > > > (at least to me) is that the 3d driver is the interaction of 3 parts:
> > > > kernel drm module, XFree driver (like radeon_dri.c) and the dri part
> > > > (whatever goes into radeon_dri.so).
> > > >
> > > > > Second, it is easiest to answer your questions if you refer to
> > > > > specific lines in specific files. There is no variable called "AGP
> > > > > Offset" anywhere in the drm. Maybe there are some with similar
> > > > > names, but I can't tell which one you're talking about.
> > > >
> > > > Finally, someone who knows the stuff :)) No, there is no such variable,
> > > > but this phrase I plucked from the comment. Here is an example from
> > > > radeon.h:
> > > >
> > > > /* CP vertex/indirect buffer data */
> > > > unsigned long bufStart; /* Offset into AGP space */
> > > > drmHandle bufHandle; /* Handle from drmAddMap */
> > > > drmSize bufMapSize; /* Size of map */
> > > > int bufSize; /* Size of buffers (in MB) */
> > > > unsigned char *buf; /* Map */
> > > > int bufNumBufs; /* Number of buffers */
> > > > drmBufMapPtr buffers; /* Buffer map */
> > > >
> > > > Now, from these I guess that *buf is where I can access the data
> > > > directly for Xserver. bufSize is the size of the thing - does it have
> > > > to be in MB ?
> > >
> > > It is interpreted as mb, hence the comment.
> >
> > Yes, I know _that_. Does it _have_ to be in mb ? can I change it to be in
> > pages and multiply every occurence by (1024*1024/PAGE_SIZE) ? In there
> > there a reason to have it in MB (aside from printing nice round numbers
> > during startup) ?
>
> No, it's just the convention that Kevin or whoever used when writing that
> driver. It could as easily be in bytes or pages or whatever you like, so
> long as everyone using it understands.
>
> Eventually it gets passed to drmMap, which expect bytes, I think.
>
> >
> > > > Or just page-aligned is fine ? bufStart - what do I use this for ? Can
> > > > I use it to reference data in the buffer or do I have to add or
> > > > subtract a magic number from it before writing into card's registers ?
> > >
> > > This is an offset from the start of the agp apperture.
> >
> > Do you know which value is used in drivers ? Offset itself or offset +
> > start ? Also, the AGP registers are set to translate the entire address
> > space - is this the AGP aperture ? Or is it something else ?
>
> The drivers map these spaces with drmMap, so they see each map as starting at
> some virtual address. When the drivers talk to the kernel it's handled on a
> case by case basis - as long as the driver and the kernel agree on the
> interpretation then everythings ok - but there's no hard and fast rule.
> Often for dma buffers, the communication is in terms of 'buffer index' which
> neither of these.
>
> I think that your problem is that you're looking for a global rule when
> really there are just lots of individual cases. The driver can use whatever
> it likes so long as the code in the kernel knows what it's talking about.
> These fields are just a communication between 2d driver and 3d driver.
>
> However, most of the values that you are interested in are eventually passed
> to drmMap and drmAddMap which have defined interfaces. If you are confused
> about a particular field, looking at how it is passed to drmMap/AddMap will
> disambiguate it to a large degree.
>
Well, this explains some things - but not all of them. Perhaps you can
point out to me where I am wrong ?
First of all, how PCI scatter-gather works: instead of having one
physically contiguous buffer to DMA in/out, we have a list of page-sized
buffers and a table (not more than a few pages long) that specifies which
ones to use. For example, in case of Radeons, the entries in the table are
16 bytes long: two are addresses, one specifies what to do with them and
one 32bit word is reserved. For bt848 the entries are 8 bytes
long: address and a command.
However, for AGP cards, AGP can do the translation by itself. So, in
principle, the AGP card should take faked contiguous buffer and work with
it.
As I am writing the driver from scratch, I will have a natural interface
boundary: the part that manages the buffers and the part that uses buffer
address (before and after AGP GART/PCI GART) for card-specific purposes.
If I am using drm/agpgart I'll have to figure out how to get the same
information - which seems unusually hard. (And since AGP GART is universal
with relation to all AGP cards there should be a unique way to arrive at
numbers to write into cards registers given DRM Handle, AGP Offset and the
like).
Now this is all fine, except I hit a brick wall: in my documentation
there are several registers that allow one to start DMA and _all_ of
those that I am interested in are supposed to point to PCI-like
scatter-gather table. Now, having a scatter-gather table in agp
translatable space is nuts. But, just ignoring AGP stuff does not work
either: first of all it does not work (experimentally) and I suspect the
reason is that the cards AGP registers are set to translate _all_
addressable space (instead of only 32mb AGP aperture). I would have tried
using space in AGP aperture except that I have no idea how to do it
(and this is the place my previous questions were about).
And for some specific questions: D
* Does it make sense to have PCI GART and AGP GART working
simultaneously ? (AGP for graphics and PCI for things like
capture).
* Do we actually need to set AGP registers to translate _all_
addresses ?
thanks
Vladimir Dergachev
> Keith
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> _______________________________________________
> Dri-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
