On Mon, 2010-09-06 at 16:31 -0700, Marek Olšák wrote:
> 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.
Lets assume your hardware doesn't understand bgrx rendertargets formats
natively, and you program it with the bgra format instead.
If so then you must do these replacements in rgb_src_factor and
rgb_dst_factor:
PIPE_BLENDFACTOR_DST_ALPHA -> PIPE_BLENDFACTOR_ONE;
PIPE_BLENDFACTOR_INV_DST_ALPHA -> PIPE_BLENDFACTOR_ZERO;
PIPE_BLENDFACTOR_SRC_ALPHA_SATURATE -> PIPE_BLENDFACTOR_ZERO;
This will ensure that's written in the red, green, and blue components
is consistent with a bgrx format (that is, destination alpha is always
one -- incoming values are discarded).
In this scenario, how you program alpha_src_factor/alpha_dst_factor is
irrelevant, because they will only affect what's written in the padding
bits, which is just padding -- it can and should be treated as
gibberish.
> 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.
IMO, there is no such thing as an "operation using the padding bits". It
is more like the contents of padding is undefined after/before any
operation. And no operation should rely on it to have any particular
value, by definition.
Alpha blending of with a bgrx format should not (and needs not) to
incorporate the padding bits for any computation. It may, however, write
anything it feels like to the padding bits as a side effect.
Now we could certainly impose the restriction in gallium that dst alpha
blendfactors will produce undefined results for bgrx (and perhaps this
is what you're arguing for). Then the burden of doing the replacements
above shifts to the statetracker. I think Keith favors that stance.
At any rate, going back to the original topic, I see no reason not to
allow bgra -> bgrx region_copy_regions.
Also, for the record, in the moment arbitrary swizzles in the texture
sampler bgrx formats became almost redundant. And I say almost because
knowning that there is no alpha in the color buffer allows for certain
optimizations (e.g., llvmpipe's swizzled layout separates the red,
green, blue, and alpha channels into different 128bit words, and will
not read/write alpha or any channel that can't be represented in the
final color buffer).
Jose
------------------------------------------------------------------------------
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
