Something that has always been requested of me as the agpgart maintainer is
for an operation that could just give someone a block of agp memory at an
arbitrary location in the aperture. I never kept around the necessary data
to make that sort of decision, however during the latest round of agpgart
development this sort of thing has become possible.
What I am thinking about is an interface something like this:
int agp_alloc_and_bind(int agp_context, int number_of_agp_pages, int
preferred_agp_page_offset,
int fail_if_offset_unavailable, u32
type_agp_of_memory);
The function would return an agp key which would designate which block of
agp memory it has acquired, the user would then call the newly provided
agp_get_map function which will give the user the details about the
allocated memory. This would be the kernel interface exported. A similar
user land interface would be provided through both the drm and /dev/agpgart
via an ioctl. This block can then be mapped using the new usermap
functionality in the drm or /dev/agpgart. If the user already has a mapping
to all of agp space it can just use the page offsets to calculate the byte
offsets necessary to obtain the proper pointers.
I also think that we would need a function to return the current keys that
are in use. That way the Xserver can keep track of the layout if it needs
to make insertion decisions without agpgart. A simple interface like the
following will probably suffice.
int agp_get_number_bytes_keylist(int agp_context);
int agp_kern_copy_keylist(int agp_context, void *buffer);
int agp_user_copy_keylist(int agp_context, void *buffer);
If the in kernel pointer is more then page size it is recommended that the
user allocate vmalloc'ed memory for the pointer, but any contiguous kernel
memory will do the job. The format of the data would be a simple bit vector
where a set bit at the ith bit would represent a key that was in use. That
way the Xserver knows which keys to query if it needs to figure out what the
aperture looks like.
I think these interfaces would allow the 3D clientside drivers to make it
alot easier to back the agp aperture dynamically. Creating new X protocol
to perform the allocation in the Xserver, and the duplication of information
that the kernel knows makes little sense. Also I can envision a day where
multiple drivers might want agp pages, and an interface like this would be
the only way to provide them all with agp memory. I think though for the
first cut of these functions should require the agp backend to be acquired,
but perhaps later we could add semantics to make the kernel the "controlling
process" as described in the agp documentation.
Does this sort of change make sense to everyone? If the quick function
prototypes don't do it for everyone, tell me and I'll write up a more formal
proposal.
Thanks,
-Jeff
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
