> 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 blend
On Mon, Sep 6, 2010 at 9:57 PM, José Fonseca 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
> > wrote:
> > I'd like to know if there's any objection to change the
> > resource_copy_region semantics to allow copies b
> When I said it won't work with decent hardware, I really meant it won't
> work due to compression. Now, it's quite possible this can be disabled
> on any chip, but you don't know that before hence you need to jump
> through hoops to get an uncompressed version of your compressed buffer
> later.
On 06.09.2010 22:03, Luca Barbieri wrote:
>>> This way you could copy z24s8 to r8g8b8a8, for instance.
>
>> I am not sure this makes a lot of sense. There's no guarantee the bit
>> layout of these is even remotely similar (and it likely won't be on any
>> decent hardware). I think the dx10 restric
Yes, if x8 is interpreted as "writes can write arbitrary data, reads
must return 1" (as you said), then this is not necessary in
resource_copy_region even if A8 -> X8 becomes supported.
You are right that format conversions would probably be better added
as a separate function (if at all), in addi
On Mon, 2010-09-06 at 10:41 -0700, Luca Barbieri wrote:
> How about dropping the idea that "resource_copy_region must be just a
> memcpy" and have the driver instruct the hardware 2D blitter to write
> 1s in the alpha channel if supported by hw or have u_blitter do this
> in the shader?
It's reall
>> This way you could copy z24s8 to r8g8b8a8, for instance.
> I am not sure this makes a lot of sense. There's no guarantee the bit
> layout of these is even remotely similar (and it likely won't be on any
> decent hardware). I think the dx10 restriction makes sense here.
Yes, it depends on the f
On Mon, 2010-09-06 at 10:22 -0700, Marek Olšák wrote:
> On Mon, Sep 6, 2010 at 3:57 PM, José Fonseca
> 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, whe
On 06.09.2010 17:16, Luca Barbieri wrote:
> On Mon, Sep 6, 2010 at 3:57 PM, José Fonseca 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:
>
How about dropping the idea that "resource_copy_region must be just a
memcpy" and have the driver instruct the hardware 2D blitter to write
1s in the alpha channel if supported by hw or have u_blitter do this
in the shader?
nv30/nv40 and apparently nv50 can do this in the 2D blitter, and all
Radeo
On Mon, Sep 6, 2010 at 3:57 PM, José Fonseca 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
On Mon, 2010-09-06 at 08:11 -0700, Roland Scheidegger wrote:
> On 06.09.2010 15:57, José Fonseca 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 for
On Mon, Sep 6, 2010 at 3:57 PM, José Fonseca 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:
I was about to propose something like this.
Ho
On 06.09.2010 15:57, José Fonseca 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
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 wil
15 matches
Mail list logo
