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
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
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:
I was about to propose
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 formats
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
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
On 06.09.2010 17:16, Luca Barbieri 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
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
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
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 really
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
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 restriction
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 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
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.
15 matches
Mail list logo
