[Mesa-dev] Should we need one release function for DRI's GLX_EXT_texture_from_pixmap?

Kristian Høgsberg krh at bitplanet.net
Thu Jan 6 05:36:47 PST 2011


On Thu, Jan 6, 2011 at 4:33 AM, Zhao, Juan J <juan.j.zhao at intel.com> wrote:
> On Wed, 2011-01-05 at 08:28 -0500, Kristian Høgsberg wrote:
>> On Tue, Jan 4, 2011 at 11:10 PM, Zhao, Juan J <juan.j.zhao at intel.com> wrote:
>> > Hi all,
>> >
>> >                 In the structure “__DRItexBufferExtensionRec”, we don’t have
>> > one release interface now. But in our platform, we need to release some
>> > resources.
>> >
>> >                 Why we don’t need the release interface? Or should we add
>> > one?
>>
>> In the open source drivers, glXBindTexImageEXT is pretty much the same
>> as glBindTexture. The pixmaps stays bound until you bind another
>> texture or pixmap, at which point all the resources are released.
>> There is nothing for the open source drivers to do in release, so the
>> DRI extension never had a release function.  If you need a release
>> function, just send a patch and we can add it.  You'll need to bump
>> the extension version number and then add the call to release in the
>> dri loaders (libGL, AIGLX, egl_dri2) conditional on the extension
>> version.
>>
> Thanks a lot! :)
> I add this interface. Would you please help to check it?
>> Kristian

Looks good, just a few commets: I don't think we need the format
argument in release do we?  I'd like to drop that to make it a little
easier to call the release function.  Also, in files in the mesa repo,
and in particular dri_interface.h, we don't need to check for
__DRI_TEX_BUFFER_VERSION >=3, since we know exactly what versions are
available.  Only the AIGLX code in X (and potentially other
out-of-tree users of the DRI driver interface) need this.  And please
keep the commit message under 80 characters wide: use a short
description in the header, then provide more detail in the following
lines, if necessary.  Finally, why do you need the invalidate call in
dri2_release_tex_image()?

Kristian


More information about the mesa-dev mailing list