Ian Romanick wrote:
Keith Whitwell wrote:

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)


replace "Dispaly" with "Display".

Also, GLX functions usually use native types like void, int, float instead of GLvoid, GLint and GLfloat (though the GLX_NV_vertex_array_range extension didn't follow that pattern).

Looks good otherwise.

-Brian





-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to