> > Changing the drm and Mesa at once incompatibly isn't going to get past me, > > and I haven't proven that Egberts patch isn't backwards compat, but nobody > > has proven to me that it doesn't break anything, and as I have no access > > to any 64-bit hardware it is up to other people to convince me ... > > The hardest bit that I have seen so far is dealing with the offset and > handle fields in the drm_map_t. I'll push on it a bit further then, > if no-one else is hacking on this.
This is a topic that we could use some clarification on, is there a "suggested" use for offset and handle. As you can imagine we(SGI) with our itanium systems have to deal with this a fair bit. My interpretation is that handle is a unique opaque identifier to a drm resource on the board (which needs to match the native word size of the platform you are running on, or unique is hard to guarantee) OTOH, offset is a value that the board manager (normally in the 2D driver in the current X setup) uses to setup/access said resources. This needs to be of the size of the bus width of the card. If this is correct, it brings up another interesting issue. How do we pass to the mmap calls 64-bit OS offsets when the actual offset (for all current gfx cards I know of) is a 32-bit entity, which brings up the reverse option to what was suggested .. should we just pass the handle instead of the offset, since that already is a kernel virtual address that linux wants. (this should work on linux platforms atleast) ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
