Ian Romanick wrote:
There are two ways to go on this. One way is to make a new GLX_MESA_memory_allocate extension that just extends the existing glXAllocateMemoryNV, glXFreeMemoryNV, and glXGetAGPOffsetMESA to take a display pointer and screen. This is by far the easiest choice and by far the least forward-looking.
The other way to go would be to implement support for ARB_vertex_array_object in the r200 driver (which is now part of the 1.5 core spec) and add a "trivial" layered extension for pixel data. Since this extension is now part of the core, and there are existing apps (i.e., UT2k3) that *really* want to use it, this is the most forward-looking approach. It will also take longer and be a lot more work. If I'm not mistaken, it will also require merging Mesa 5.1 to DRI...and that ain't gonna happen for awhile.
So, here's the question of the day: do you & your customers need the existing functionality in XFree86 or just in the embedded branch? If the latter, then I'd like to axe it just from the DRI trunk and work towards the 2nd option.
We need it specifically in the DRI. I'd be relatively happy with the first proposal as a stop-gap measure.
Attached is the spec I whipped up for GLX_MESA_allocate_memory. Keith, does this suit your short-term needs? If so, I should be able to replace the existing implementation of the GLX_NV_vertex_array_range allocator with this one quickly after Felix commits his changes.
Name
MESA_allocate_memory
Name Strings
GLX_MESA_allocate_memory
Contact
Ian Romanick, IBM, Inc. (idr 'at' us.ibm.com)
Keith Whitwell, Tungsten Graphics, Inc. (keith 'at' tungstengraphics.com)
Status
Shipping (Mesa 5.1 and later. Only implemented in particular
XFree86/DRI drivers.)
Version
1.0
Number
TBD
Dependencies
OpenGL 1.0 or later is required
GL_NV_vertex_array_range trivially effects the definition of this
extension.
This extensions is written against the OpenGL 1.4 Specification.
Overview
This extension allows applications to directly allocate on-card or
AGP memory for use with a particular display / screen. It
additionally provides a way to convert pointers in on-card / AGP memory
into a byte offset.
This extension replaces GLX_NV_vertex_array_range, for which no real
specification exists. See GL_NV_vertex_array_range for more information.
GLX_NV_vertex_array_range (and GLX_NV_pixel_data_range) are both
deficient in that they assume that only a single graphics card
will be installed in the system. They provide no way to specify
which card's memory space the allocation should take place in, nor
is a valid context required. This extension fixes that deficiency.
Note that this extension is a stop-gap solution. It exists solely
to expose certain functionality in a few drivers. Once
ARB_vertex_buffer_object and ARB_pixel_buffer_object are available
in DRI / Mesa, this extension will be depricated and removed in
short order.
IP Status
None
Issues
None
New Procedures and Functions
GLvoid *glXAllocateMemoryMESA(Dispaly *dpy, int scrn, GLsizei size,
GLfloat readFreq, GLfloat writeFreq,
GLfloat priority)
GLvoid glXFreeMemoryMESA(Dispaly *dpy, int scrn, GLvoid *pointer)
GLuint glXGetMemoryOffsetMESA(Dispaly *dpy, int scrn,
const GLvoid *pointer)
New Tokens
None
Additions to the OpenGL 1.4 Specification
None
Additions to Chapter 3 the GLX 1.4 Specification (Functions and Errors)
Add a new section, 3.6 as follows:
3.6 Graphics Memory Access
Certain graphics operations, such as using NV_vertex_array_range
or other extensions, require the direct use of driver managed
graphics memory. The commands
void *glXAllocateMemoryMESA(sizei size,
float readFrequency,
float writeFrequency,
float priority)
void glXFreeMemoryMESA(void *pointer)
provide a means for an application to allocate and free memory
that may be more suitable for these operations. The
glXAllocateMemoryMESA command allocates <size> bytes of contiguous
memory.
The <readFrequency>, <writeFrequency>, and <priority> parameters are
usage hints that the OpenGL implementation can use to determine the
best type of memory to allocate. These parameters range from 0.0
to 1.0. A <readFrequency> of 1.0 indicates that the application
intends to frequently read the allocated memory; a <readFrequency>
of 0.0 indicates that the application will rarely or never read the
memory. A <writeFrequency> of 1.0 indicates that the application
intends to frequently write the allocated memory; a <writeFrequency>
of 0.0 indicates that the application will rarely write the memory.
A <priority> parameter of 1.0 indicates that memory type should be
the most efficient available memory, even at the expense of (for
example) available texture memory; a <priority> of 0.0 indicates that
the vertex array range does not require an efficient memory type
(for example, so that more efficient memory is available for other
purposes such as texture memory).
The OpenGL implementation is free to use the <size>, <readFrequency>,
<writeFrequency>, and <priority> parameters to determine what memory
type should be allocated. The memory types available and how the
memory type is determined is implementation dependent (and the
implementation is free to ignore any or all of the above parameters).
Possible memory types that could be allocated are uncached memory,
write-combined memory, graphics hardware memory, etc. The intent
of the glXAllocateMemoryMESA command is to permit the allocation of
memory for efficient usage with certain other extensions.
However, there is no requirement that memory allocated by
glXAllocateMemoryMESA must be used to allocate memory for use with
those extensions. That is, an application could use the memory
for any purpose it wants.
If the memory cannot be allocated, a NULL pointer is returned (and
no OpenGL error is generated). An implementation that does not
support this extension's memory allocation interface is free to
never allocate memory (always return NULL).
The glXFreeMemoryMESA command frees memory allocated with
glXAllocateMemoryMESA. The <pointer> should be a pointer returned by
glXAllocateMemoryMESA and not previously freed. If a pointer is passed
to glXFreeMemoryMESA that was not allocated via glXAllocateMemoryMESA
or was previously freed (without being reallocated), the free is
ignored with no error reported.
The memory allocated by glXAllocateMemoryMESA should be available to
all other threads in the address space where the memory is allocated
(the memory is not private to a single thread). Any thread in the
address space (not simply the thread that allocated the memory)
may use glXFreeMemoryMESA to free memory allocated by itself or any
other thread.
Because glXAllocateMemoryMESA and glXFreeMemoryMESA are not OpenGL
rendering commands, these commands do not require a current context.
They operate normally even if called within a Begin/End or while
compiling a display list.
It is sometimes useful to know the byte-offset of an allocation
made with glXAllocateMemoryMESA within its memory area. The function
GLuint glXGetMemoryOffsetMESA( Display *dpy, int scrn,
const GLvoid *pointer )
Returns the offset of the given memory block from the start of the
memory region in basic machine units (i.e. bytes). If <pointer>
is invalid the value ~0 will be returned.
Using memory allocated with glXAllocateMemoryMESA with a GL
context bound to a drawable on a display and screen other than the
one where it was allocated will produce undefined results.
GLX Protocol
None. This is a client side-only extension.
Errors
glXAllocateMemoryMESA will return NULL if insufficient memory is
available or if the memory allocation interface is not supported.
glXGetMemoryOffsetMESA will return ~0 if the pointer does not point to
an AGP memory region.
New State
None
Revision History
20 September 2002 - Initial draft
2 October 2002 - finished GLX chapter 3 additions
11 August 2003 - Converted from MESA_agp_offset to
MESA_allocate_memory. Merged in details of the memory
allocation interface from NV_vertex_array_range.
