- Original Message -
[...]
Anyway, you guys are doing it, and it doesn't seem like Keith or Brian have
an opinion, so as far as I'm concerned, feel free to decide among yourselves
and start coding away in a branch.
I only have two requirements:
- there must be no regression on
After wasting so much time on this topic, and conceding on most points, I'm
disappointed that the new pure integers formats were added without support
for converting to/from floats (my 2nd request above) which ended up causing
obscures bugs in llvmpipe (my 1st request).
I regret having
On Tue, Nov 1, 2011 at 2:11 PM, Dave Airlie airl...@gmail.com wrote:
After wasting so much time on this topic, and conceding on most points, I'm
disappointed that the new pure integers formats were added without support
for converting to/from floats (my 2nd request above) which ended up
Agree.
So who is going to do that? Dave and Marek seems to already have
volunteered for that. I would also like to help, but at least officially
I don't have time todo so.
I've started on separate int types in my
http://cgit.freedesktop.org/~airlied/mesa/log/?h=gallium-int-work
This plumbs
Am Freitag, den 16.09.2011, 12:58 -0700 schrieb Jose Fonseca:
[SNIP]
This change would be best to describe a vertex and texture fetch as
implemented by Radeons:
diff --git a/src/gallium/auxiliary/util/u_format.h
b/src/gallium/auxiliary/util/u_format.h
index 2eb3e1b..8c4d67f 100644
José,
I understand what you are trying to tell me, but it's not good enough
to convince me. I am mainly advocating what maps nicely to my hardware
and what appears to be a sane long-term solution in my opinion. The
Translate example might not be relevant, because it doesn't work how
hardware
- Original Message -
On Fri, Sep 16, 2011 at 5:40 PM, Jose Fonseca jfons...@vmware.com
wrote:
- Original Message -
José,
I understand what you are trying to tell me, but it's not good
enough
to convince me. I am mainly advocating what maps nicely to my
hardware
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/12/2011 11:41 AM, Jose Fonseca wrote:
- Original Message -
On Mon, Sep 12, 2011 at 5:48 PM, Roland Scheidegger
srol...@vmware.com wrote:
Am 11.09.2011 19:17, schrieb Dave Airlie:
On Sun, Sep 11, 2011 at 10:11 AM, Dave Airlie
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/13/2011 11:23 AM, Jose Fonseca wrote:
- Original Message -
I've attached a rough outline of a patch to add a
bind_as_integer flag for vertex elements, sampler views and
surfaces.
I don't mind as_integer but I wonder if as_float
- Original Message -
Am 13.09.2011 00:33, schrieb Jose Fonseca:
I admit I'm not very familiar how hardware currently supports
native
double formats. Or how likely it is for hardware to have native 4
x
double register support in the future. But even if we ignore the 4
x
Am 13.09.2011 18:31, schrieb Jose Fonseca:
- Original Message -
Am 13.09.2011 00:33, schrieb Jose Fonseca:
I admit I'm not very familiar how hardware currently supports
native double formats. Or how likely it is for hardware to have
native 4 x double register support in the
José, Roland,
there is a problem with the proposed approach of having the
convert_to_float flag. That flag might not be supported for certain
integer formats. We would need to update some more places, e.g.
is_format_supported:
boolean (*is_format_supported)( struct pipe_screen *,
- Original Message -
José, Roland,
there is a problem with the proposed approach of having the
convert_to_float flag. That flag might not be supported for certain
integer formats. We would need to update some more places, e.g.
is_format_supported:
boolean
- Original Message -
The translate module also needs to distinguish between scaled and
integer types. Translate currently doesn't support integers, only
scaled. The code in Translate would either have to look like this:
case PIPE_FORMAT_R32_SSCALED:
return is_int ?
Am 13.09.2011 20:45, schrieb Jose Fonseca:
- Original Message -
José, Roland,
there is a problem with the proposed approach of having the
convert_to_float flag. That flag might not be supported for
certain integer formats. We would need to update some more places,
e.g.
On Tue, Sep 13, 2011 at 8:45 PM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
José, Roland,
there is a problem with the proposed approach of having the
convert_to_float flag. That flag might not be supported for certain
integer formats. We would need to update some
- Original Message -
Am 13.09.2011 20:45, schrieb Jose Fonseca:
- Original Message -
José, Roland,
there is a problem with the proposed approach of having the
convert_to_float flag. That flag might not be supported for
certain integer formats. We would need to
Am 13.09.2011 21:39, schrieb Jose Fonseca:
- Original Message -
Am 13.09.2011 20:45, schrieb Jose Fonseca:
- Original Message -
José, Roland,
there is a problem with the proposed approach of having the
convert_to_float flag. That flag might not be supported for
- Original Message -
On Tue, Sep 13, 2011 at 8:45 PM, Jose Fonseca jfons...@vmware.com
wrote:
- Original Message -
José, Roland,
there is a problem with the proposed approach of having the
convert_to_float flag. That flag might not be supported for
certain
- Original Message -
On 12.09.2011 21:14, Jose Fonseca wrote:
- Original Message -
Am 12.09.2011 19:05, schrieb Christoph Bumiller:
On 12.09.2011 18:41, Jose Fonseca wrote:
- Original Message -
On Mon, Sep 12, 2011 at 5:48 PM, Roland Scheidegger
Hi guys,
not really finding a great explaination in my 2 minute search, of what
the USCALED and SSCALED types are representative of
On r600 hw at least we have a SCALED type, which seems to be an
integer in float point format, as well as an INT type which is natural
integers.
Are the gallium
On Sun, Sep 11, 2011 at 10:11 AM, Dave Airlie airl...@gmail.com wrote:
Hi guys,
not really finding a great explaination in my 2 minute search, of what
the USCALED and SSCALED types are representative of
On r600 hw at least we have a SCALED type, which seems to be an
integer in float point
22 matches
Mail list logo
