Re: [Dri-devel] Using drm (fwd)

2001-10-13 Thread volodya



Well, it is late Saturday here. I know everyone is busy, but can at least
someone confirm that they know the answer but just don't have time for it ?
I'd hate to lose a weekend waiting for something that's not going to
come..

Vladimir Dergachev


-- Forwarded message --
Date: Wed, 10 Oct 2001 18:08:50 -0400 (EDT)
From: [EMAIL PROTECTED]
To: Keith Whitwell [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [Dri-devel] Using drm (fwd)



On Wed, 10 Oct 2001, Keith Whitwell wrote:

 On Wed, 10 Oct 2001 15:45, [EMAIL PROTECTED] wrote:
  On Wed, 10 Oct 2001, Daryll Strauss wrote:
   On Wed, Oct 10, 2001 at 05:13:40PM -0400, [EMAIL PROTECTED] wrote:
So, can anyone answer any of the questions below, or do I have to write
drm for multimedia ?
  
   The DRM is an architecture for accessing hardware directly.
  
   What functions are implemented in any given kernel module is driven by
   the requirements of the applications running on top of it. That's
   typically OpenGL at that point.
 
  Daryll, did you read the questions ? I am asking specific things about drm
  interface. Like what drm handles mean, for example.
 
   So, most of the drivers are not going to have a function call to support
   your arbitrary DMA.
 
  I am not interested in most drivers. Heck, I am not even looking for that
  function. I want to know what can I do with the buffer I allocated using
  drm.
 
  Now, I aprreciate your desire to provide some advice, but I am not
  interested in general considerations of writing a DMA driver. I want to
  know answers to specific questions, like
 
What AGP Offset is used for ?
 
  it is not specific to any card, it is not specific to what I am trying to
  do. Can anyone answer it ?
 
 First, your best bet is to read and understand the 3d driver associated with 
 whatever hardware you're looking at.  Most of the questions you are asking 
 can be most easily answered by examination of the code.  

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 ?
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 ? (and to answer
your questions: I have made a copy of the same fields /with buf replaced
with capture and allocated space.. nothing seems to crash.., 3d workds,
1mb is reserved someplace. /)


 Thirdly, nobody's got the time or patience to explain the entire workings of 
 the drm to you.  Make an honest attempt to read and understand the code.  Ask 
 a few questions and you'll get a few answers.  Ask a thousand questions and 
 you will be lucky to get any at all.

Ok, I'll leave the other questions for later.

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



Re: [Dri-devel] Using drm (fwd)

2001-10-13 Thread Keith Whitwell



--  Forwarded Message  --
Subject: Re: [Dri-devel] Using drm (fwd)
Date: Sat, 13 Oct 2001 16:42:59 -0600
From: Keith Whitwell [EMAIL PROTECTED]
To: [EMAIL PROTECTED]


 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.

 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.

These fields are setup in the 2d driver to tell the 3d driver how memory is
layed out.  Have a look at radeon_dri.c to see how agp space is partitioned
up and these values are calculated.

 (and to answer
 your questions: I have made a copy of the same fields /with buf replaced
 with capture and allocated space.. nothing seems to crash.., 3d workds,
 1mb is reserved someplace. /)

I don't think that copying these fields is going to reserve you any memory.
You'll need to modify radeon_dri.c to actually reserve memory.  If you add a
field called 'KeithIsAMillionaire', it doesn't automatically make me rich...

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



Re: [Dri-devel] Using drm (fwd)

2001-10-10 Thread volodya



So, can anyone answer any of the questions below, or do I have to write
drm for multimedia ?

 thanks

  Vladimir Dergachev


 interface of doing captures. I'm currently working on a new Xv function
 (XvShmGetImage) that will do this, and also when I see some code from your

I am asking about a different problem - not how to get the data from X to
the client, but how to ask drm nicely to make a DMA transfer. I suspect
(!) that I can simply write the correct values into the registers and the
DMA will happen, but I am not clear about the semantics. For example, is 
AGP Offset the address from the point of view of video card or something
else ? Do I have to subtract framebuffer address from it ? What is the
significance of card specific drm structures ? Why do we need them ? Why
have a separate area for textures ? Can I modify it dynamically ? (so as
not to reserve 1mb chunk of ram for capture buffer). What drm handles are
for and whether there is a small test app that exercises drm interface
from command line (i.e. not inside Xserver or glx client). What do I do
about IRQ support ? there seems to be no mention of it in drm structures,
but there are a number of IRQs that could occur (vsync, hsync, DMA
completion (several different sources, i.e. 4 VIP, textures, command
processor..)) Each time irq happens the handler needs to acknowledge it or
the system will hang (it will keep entering the handler).

Not to mention: how do I behave nicely w.r.t. other DMA transfers ? Lock
them, flush queues, etc. ?


At the moment I just want a hacked Xserver that does a DMA transfer from
video memory into plain RAM. Or an Xserver with usermode app that does DMA
transfer - I don't care.

   


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



Re: [Dri-devel] Using drm (fwd)

2001-10-10 Thread Daryll Strauss

On Wed, Oct 10, 2001 at 05:13:40PM -0400, [EMAIL PROTECTED] wrote:
 So, can anyone answer any of the questions below, or do I have to write
 drm for multimedia ?

The DRM is an architecture for accessing hardware directly.

What functions are implemented in any given kernel module is driven by
the requirements of the applications running on top of it. That's
typically OpenGL at that point.

So, most of the drivers are not going to have a function call to support
your arbitrary DMA.

You don't need to write a drm for multimedia you need to add the hooks
you require into the exsting kernel modules for various graphics
cards. When do you do this, be careful to consider the security
implications. Make sure it can't be used to read or write things that it
shouldn't. Also make sure it cooperates with the existing driver in the
way it uses memory on the card, the state it leaves the card in after
its operations, etc.

- |Daryll


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



Re: [Dri-devel] Using drm (fwd)

2001-10-10 Thread volodya



On Wed, 10 Oct 2001, Daryll Strauss wrote:

 On Wed, Oct 10, 2001 at 05:13:40PM -0400, [EMAIL PROTECTED] wrote:
  So, can anyone answer any of the questions below, or do I have to write
  drm for multimedia ?
 
 The DRM is an architecture for accessing hardware directly.
 
 What functions are implemented in any given kernel module is driven by
 the requirements of the applications running on top of it. That's
 typically OpenGL at that point.

Daryll, did you read the questions ? I am asking specific things about drm
interface. Like what drm handles mean, for example.

 
 So, most of the drivers are not going to have a function call to support
 your arbitrary DMA.

I am not interested in most drivers. Heck, I am not even looking for that
function. I want to know what can I do with the buffer I allocated using
drm. 

Now, I aprreciate your desire to provide some advice, but I am not
interested in general considerations of writing a DMA driver. I want to
know answers to specific questions, like

  What AGP Offset is used for ?

it is not specific to any card, it is not specific to what I am trying to
do. Can anyone answer it ?

   Vladimir Dergachev

 
 You don't need to write a drm for multimedia you need to add the hooks
 you require into the exsting kernel modules for various graphics
 cards. When do you do this, be careful to consider the security
 implications. Make sure it can't be used to read or write things that it
 shouldn't. Also make sure it cooperates with the existing driver in the
 way it uses memory on the card, the state it leaves the card in after
 its operations, etc.
 
   - |Daryll
 


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



Re: [Dri-devel] Using drm (fwd)

2001-10-10 Thread Keith Whitwell



 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 ?
 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 ? (and to answer
 your questions: I have made a copy of the same fields /with buf replaced
 with capture and allocated space.. nothing seems to crash.., 3d workds,
 1mb is reserved someplace. /)

I'll check up  give you proper answers in a sec.  However, it sounds like 
you're just looking to allocate a buffer of a meg or two on the card 
somewhere and use that for some purpose.  If so, the 3d drivers are doing 
this all the time - to hold textures.  You should be able to do the same 
thing - just grab a meg or two of texture memory and use that for your 
purposes.  You'll need a trick or two to stop others grabbing it back when 
resources run low, but it is doable without modifying any kernel structures.  
Have a look at the files in lib/GL/mesa/src/drv/XYZ/*_tex*.[ch] and in 
particular functions like i810UploadTexImages() which scan the LRU and 
allocate memory.

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



Re: [Dri-devel] Using drm (fwd)

2001-10-10 Thread volodya



On Wed, 10 Oct 2001, Keith Whitwell wrote:

 
 
  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 ?
  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 ? (and to answer
  your questions: I have made a copy of the same fields /with buf replaced
  with capture and allocated space.. nothing seems to crash.., 3d workds,
  1mb is reserved someplace. /)
 
 I'll check up  give you proper answers in a sec.  However, it sounds like 
 you're just looking to allocate a buffer of a meg or two on the card 
 somewhere and use that for some purpose.  If so, the 3d drivers are doing 
 this all the time - to hold textures.  You should be able to do the same 
 thing - just grab a meg or two of texture memory and use that for your 
 purposes.  You'll need a trick or two to stop others grabbing it back when 

No, no, I have no trouble allocating RAM. I don't know what to do with it
next. 

I understand how scatter-gather works from looking at bt848 driver. I
believe I know the generalities of PCI GART and AGP GART for ATI cards.
The problem is I don't understand the specifics. Here is a more involved
explanation (all for Radeon as this is what I have plugged in now,
besides the docs are more thorough):

There is a DMA_VIP0_TABLE_ADDR which accepts a 32 bit address of a table
of commands for DMA transfer. Looking at the docs it seems that the
transfer is initiated by writing the total number of bytes to transfer in 
VIPH_CH0_SBCNT. Now, I know the format of the table. But, when I try
writing the physical address of the page to make the transfer nothing
(useful) happens. So, I guess it goes thru some kind of translation. But
which ? Both PCI GART and AGP GART are supposed to straighten memory by
themselves so an extra indirect should not be necessary. Furthermore,
which addresses need to be written in the table - physical or not ? 
Now, I could have tried all combinations, except that I don't even know
that I am using the right register. There are several DMA engines in the
card: 4 VIP ones, GUI, and others. The bmaster example uses GUI to
transfer image into main memory, but there is no example of transfer back. 
Now, the decoder chip is located on VIP bus (which is only one for the
whole card), but there are 4 VIP DMA channels with cryptic statement of
only 2 DMA transfers could be active in the queue in the same time. Does
that mean 2 transfers from VIP devices or one VIP and one 3d I don't know
either. As you can see this multiplies  the choices significantly. So I
want to reduce them by eliminating guesswork from address things.

Which brings back the question about AGP offset - what is this ?

   thanks

 Vladimir Dergachev

PS And, in case it helps, here is a list of things I already tried:
standalone kernel module, with ram allocated by rvmalloc from bt848. 
It seems to both work and not. I see address changing in the DMA status
registers, but I don't get End of DMA interrupts. And I don't get any
data in the buffers. No lockups though. I tried allocating ram using drm.
I can allocate it fine. I don't know what to do with it next (as I can get
to physical addresses from within X to form a DMA transfer table. And I
don't see any code in X making such a table).


 resources run low, but it is doable without modifying any kernel structures.  
 Have a look at the files in lib/GL/mesa/src/drv/XYZ/*_tex*.[ch] and in 
 particular functions like i810UploadTexImages() which scan the LRU and 
 allocate memory.
 
 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