On Tue, May 17, 2011 at 07:15:50PM +0200, Michel Dänzer wrote: > On Die, 2011-05-17 at 18:59 +0200, Marcin Slusarz wrote: > > On Tue, May 17, 2011 at 06:40:02PM +0200, Michel Dänzer wrote: > > > On Die, 2011-05-17 at 18:30 +0200, Marcin Slusarz wrote: > > > > On Tue, May 17, 2011 at 09:27:45AM +0200, Michel Dänzer wrote: > > > > > On Die, 2011-05-17 at 00:12 +0200, Marcin Slusarz wrote: > > > > > > On Mon, May 16, 2011 at 10:51:58PM +0200, Roland Scheidegger wrote: > > > > > > > Otherwise, doesn't really look hacky to me - unless we could get > > > > > > > other > > > > > > > channel ordering or something similar... > > > > > > > > > > > > It makes assumptions about how color components are ordered and > > > > > > what are > > > > > > their widths - e.g. it can't distinguish r5g6b5 from a1r5g5b5. > > > > > > > > > > Such assumptions should be fine for non-RENDER operations. For RENDER, > > > > > maybe you could use something like exaGetRGBAFromPixel, at least for > > > > > inspiration. > > > > > > > > The problem is that exa does not pass format to PrepareSolid - only raw > > > > color > > > > data and depth, but pipe_context->clear wants float[4], so we need to > > > > figure > > > > out color format first. (Or add raw_clear operation...) > > > > > > The format can be determined from the destination pixmap if necessary? > > > > I couldn't find it. How to do it? > > priv->tex is the underlying texture, so priv->tex->format should be what > you need.
Maybe I'm missing something, but I think priv->tex is only allocated by ExaModifyPixmapHeader, which guesses format from depth (see exa_get_pipe_format)... Marcin _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
