[Mesa3d-dev] Re: GLX_EXT_texture_from_pixmap

[Adam Jackson]

On Tuesday 07 February 2006 00:51, Ian Romanick wrote:
> Adam Jackson wrote:
> > In the future
> > there's probably some integration to be done with the GetImage path for
> > accelerated downloads, or with on-card copies from pixmap storage to
> > texture storage, or live updates as mentioned above.
>
> Why?  We ought to just optimize the driver to realize, "Hey, that
> texture source address is in on-card memory.  I can do something smart
> with that!"  That may mean that we need to do some hackery for the
> server-side software rasterizer, but it seems like it should be 99%
> containable in the 3D code.

Yes, that's what I said. ;)  That the integration need not happen in libglx 
necessarily, doesn't make it not integration.

If you have a software rasterizer in the the brave new AIGLX world, then your 
texture data really badly needs to live in host memory if you want to have 
any hope of moderately acceptable performance.  This situation reduces to 
software rendering as it is now.  So to convert pixmap image data to texture 
image data (remember, you can still have 2d accel a la EXA), you want those 
bits out of the framebuffer as fast as possible.  In other words, if the 
pixmap image is in framebuffer memory, you want X's GetImage call chain with 
DMA or assembly memcpy backing it up.

However if your server-side GL engine is hardware backed - and about time! - 
then your driver should be able to look at the pointer you hand it in 
TexImage and do something intelligent with it.  Like, say, card-to-card blit, 
or texture in place, depending on the semantics of EXT_tfp that we end up 
with and/or the user asks for.

I think it will end up being slightly difficult to express this in a generic 
fashion within libglx, given the above two models and the heavy GART case of 
like the i915, so we may need to add the EXT_tfp entrypoints to the DRI 
driver dispatch somehow.  No big deal.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20060207/14dee851/attachment.pgp>