On Mon, Sep 6, 2010 at 9:57 PM, José Fonseca <jfons...@vmware.com> wrote:
> On Mon, 2010-09-06 at 10:22 -0700, Marek Olšák wrote:
> > On Mon, Sep 6, 2010 at 3:57 PM, José Fonseca <jfons...@vmware.com>
> > wrote:
> > I'd like to know if there's any objection to change the
> > resource_copy_region semantics to allow copies between
> > different yet
> > compatible formats, where the definition of compatible formats
> > is:
> >
> > "formats for which copying the bytes from the source resource
> > unmodified to the destination resource will achieve the same
> > effect of a
> > textured quad blitter"
> >
> > There is an helper function util_is_format_compatible() to
> > help making
> > this decision, and these are the non-trivial conversions that
> > this
> > function currently recognizes, (which was produced by
> > u_format_compatible_test.c):
> >
> > b8g8r8a8_unorm -> b8g8r8x8_unorm
> >
> > This specific case (and others) might not work, because there are no
> > 0/1 swizzles when blending pixels with the framebuffer, e.g. see this
> > sequence of operations:
> > - Blit from b8g8r8a8 to b8g8r8x8.
> > - x8 now contains a8.
> > - Bind b8g8r8x8 as a colorbuffer.
> > - Use blending with the destination alpha channel.
> > - The original a8 is read instead of 1 (x8) because of lack of
> > swizzles.
>
> This is not correct. Or at least not my interpretation.
>
> The x in b8g8r8x8 means padding (potentially with with unitialized
> data). There is no implicit guarantee that it will contain 0xff or
> anything.
>
> When blending to b8g8r8x8, destination alpha is by definition 1.0. It is
> an implicit swizzle (see e.g., u_format.csv).
>
> If the hardware's fixed function blending doesn't understand bgrx
> formats natively, then the pipe driver should internally replace the
> destination alpha factor factor with one. It's really simple. See for
>
The dst blending parameter is just a factor the real dst value is multiplied
by (except for min/max). There is no way to multiply an arbitrary value by a
constant and get 1.0. But you can force 0, of course. I don't think there is
hardware which supports such flexible swizzling in the blender. If x8 is
just padding as you say, the value of it should be undefined and every
operation using the padding bits should be undefined too except for texture
sampling. It's not like I have any other choice.
Marek
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
