Hi,

in the Savage driver I will have to pass vertex data to the kernel. On
Savage3D/IX/MX I have worked out how to do real vertex DMA, so this is
no problem. On Savage4 the vertex DMA engine can't cope with all vertex
formats, so I need to used drawing commands with inline vertex data
sometimes. So I see two choices for how to get the vertex data from user
space to the kernel:

      * shared memory buffers created by the Xserver
        advantages:
              * as long as I don't use command DMA it avoids one extra
                copy
        disadvantages:
              * limited number of buffers
              * static allocation at xserver startup
      * copy from user
        advantages:
              * dynamic memory allocation (at client startup)
        disadvantages:
              * extra copy if I don't use command DMA (need to use
                memcpy_mmio which doesn't exist as copy_from_user)

Since I'm going to implement command DMA on Savage4 eventually, I'd
prefer the "copy from user" method. However, I remember reading about
64-bit issues with user pointers in data structures passed between
kernel and user-space. Is there any 64-bit clean way of copying a vertex
buffer from user-space. I guess the only way would be to pass the
pointer directly as ioctl argument. Then all extra information (like
vertex format and number of vertices) would have to be in a header of
that vertex buffer. Am I on the right track so far?

Thanks,
  Felix

-- 
| Felix Kühling <[EMAIL PROTECTED]>                     http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3  B152 151C 5CC1 D888 E595 |



-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to