subject:"\[Mesa\-dev\] \[PATCH 3\/6\] glsl\: move half<\->float convertion to util"

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

2015-10-12 Thread Rob Clark

On Mon, Oct 12, 2015 at 12:47 AM, Jason Ekstrand  wrote:
>> > +/**
>> > + * Convert a 2-byte half float to a 4-byte float.
>> > + * Based on code from:
>> > + * http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/008786.html
>> > + */
>> > +static inline float
>> > +_mesa_half_to_float(GLhalfARB val)
>> > +{
>> > +   return half_to_float(val);
>> > +}
>
> This is kind of ugly. How hard would it really be to just replace the uses
> with the new name?  I don't think its used *that* often.

hmm, ~20-30 call sites.. not impossible to update them all, but I
think it should be a separate patch and then drop the compat shims
rather than one big patch that changes everything..

We could also keep the _mesa_half_to_float() name.. but I really
wanted to drop the GLhalfARB and not drag along GL typedefs.  If no
one objects to just replacing GLhalfARB with uint16_t.

I could go either way.

>> > +
>> > +#include 
>> > +
>> > +#ifdef __cplusplus
>> > +extern "C" {
>> > +#endif
>> > +
>> > +uint16_t float_to_half(float val);
>> > +float half_to_float(uint16_t val);
>>
>> I think these functions need to be prefixed with something -- util_*
>> or something or just leave them as _mesa_*.
>
> Unfortunately, until is kind of a grab-bag right now.  Some stuff has a
> util_ prefix, some has kept its _mesa_ or u_ prefix depending on whether it
> was copied from Mesa or gallium, and some (hash_table for example) isn't
> prefixed at all.  Personally, I'd go with either util_ (it is a utility
> library) or just keep _mesa_ (this is still the mesa project after all). I'm
> not going to be too insistent though

the util_ prefix conflicts w/ u_half.h (which appears to implement
basically the same thing in a simpler way, but maybe not compatible
enough to just switch to the gallium implementation?  Otherwise the
easier approach would be to just move the gallium implementation to
global util directory and use that instead)..  I was going to use
convert_ prefix but that also conflicts..

BR,
-R
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

2015-10-12 Thread Rob Clark

On Mon, Oct 12, 2015 at 2:22 PM, Matt Turner  wrote:
> On Mon, Oct 12, 2015 at 11:12 AM, Rob Clark  wrote:
>> On Mon, Oct 12, 2015 at 12:47 AM, Jason Ekstrand  
>> wrote:
 > +/**
 > + * Convert a 2-byte half float to a 4-byte float.
 > + * Based on code from:
 > + * http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/008786.html
 > + */
 > +static inline float
 > +_mesa_half_to_float(GLhalfARB val)
 > +{
 > +   return half_to_float(val);
 > +}
>>>
>>> This is kind of ugly. How hard would it really be to just replace the uses
>>> with the new name?  I don't think its used *that* often.
>>
>> hmm, ~20-30 call sites.. not impossible to update them all, but I
>> think it should be a separate patch and then drop the compat shims
>> rather than one big patch that changes everything..
>>
>> We could also keep the _mesa_half_to_float() name.. but I really
>> wanted to drop the GLhalfARB and not drag along GL typedefs.  If no
>> one objects to just replacing GLhalfARB with uint16_t.
>>
>> I could go either way.
>
> Replacing GLhalfARB with uint16_t seems like a good plan.

ok, then the most straightforward (least churn) approach seems to be
to keep the _mesa_ prefix but use uint16_t..

 > +
 > +#include 
 > +
 > +#ifdef __cplusplus
 > +extern "C" {
 > +#endif
 > +
 > +uint16_t float_to_half(float val);
 > +float half_to_float(uint16_t val);

 I think these functions need to be prefixed with something -- util_*
 or something or just leave them as _mesa_*.
>>>
>>> Unfortunately, until is kind of a grab-bag right now.  Some stuff has a
>>> util_ prefix, some has kept its _mesa_ or u_ prefix depending on whether it
>>> was copied from Mesa or gallium, and some (hash_table for example) isn't
>>> prefixed at all.  Personally, I'd go with either util_ (it is a utility
>>> library) or just keep _mesa_ (this is still the mesa project after all). I'm
>>> not going to be too insistent though
>>
>> the util_ prefix conflicts w/ u_half.h (which appears to implement
>> basically the same thing in a simpler way, but maybe not compatible
>> enough to just switch to the gallium implementation?  Otherwise the
>> easier approach would be to just move the gallium implementation to
>> global util directory and use that instead)..  I was going to use
>> convert_ prefix but that also conflicts..
>
> Seems valuable to ultimately remove the Gallium implementation as
> well. Chad did some really tedious work to improve the functions
> you're moving to round properly.

hmm, looks like his change was mostly important for compiler (to match
what intel hw does).. otoh I guess it shouldn't hurt for gallum (which
looks to be used mostly for texture/format conversion) and would be
nice to de-duplicate..
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

2015-10-12 Thread Matt Turner

On Mon, Oct 12, 2015 at 11:12 AM, Rob Clark  wrote:
> On Mon, Oct 12, 2015 at 12:47 AM, Jason Ekstrand  wrote:
>>> > +/**
>>> > + * Convert a 2-byte half float to a 4-byte float.
>>> > + * Based on code from:
>>> > + * http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/008786.html
>>> > + */
>>> > +static inline float
>>> > +_mesa_half_to_float(GLhalfARB val)
>>> > +{
>>> > +   return half_to_float(val);
>>> > +}
>>
>> This is kind of ugly. How hard would it really be to just replace the uses
>> with the new name?  I don't think its used *that* often.
>
> hmm, ~20-30 call sites.. not impossible to update them all, but I
> think it should be a separate patch and then drop the compat shims
> rather than one big patch that changes everything..
>
> We could also keep the _mesa_half_to_float() name.. but I really
> wanted to drop the GLhalfARB and not drag along GL typedefs.  If no
> one objects to just replacing GLhalfARB with uint16_t.
>
> I could go either way.

Replacing GLhalfARB with uint16_t seems like a good plan.

>>> > +
>>> > +#include 
>>> > +
>>> > +#ifdef __cplusplus
>>> > +extern "C" {
>>> > +#endif
>>> > +
>>> > +uint16_t float_to_half(float val);
>>> > +float half_to_float(uint16_t val);
>>>
>>> I think these functions need to be prefixed with something -- util_*
>>> or something or just leave them as _mesa_*.
>>
>> Unfortunately, until is kind of a grab-bag right now.  Some stuff has a
>> util_ prefix, some has kept its _mesa_ or u_ prefix depending on whether it
>> was copied from Mesa or gallium, and some (hash_table for example) isn't
>> prefixed at all.  Personally, I'd go with either util_ (it is a utility
>> library) or just keep _mesa_ (this is still the mesa project after all). I'm
>> not going to be too insistent though
>
> the util_ prefix conflicts w/ u_half.h (which appears to implement
> basically the same thing in a simpler way, but maybe not compatible
> enough to just switch to the gallium implementation?  Otherwise the
> easier approach would be to just move the gallium implementation to
> global util directory and use that instead)..  I was going to use
> convert_ prefix but that also conflicts..

Seems valuable to ultimately remove the Gallium implementation as
well. Chad did some really tedious work to improve the functions
you're moving to round properly.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

2015-10-12 Thread Rob Clark

On Mon, Oct 12, 2015 at 3:41 PM, Roland Scheidegger  wrote:
> Am 12.10.2015 um 20:33 schrieb Rob Clark:
>> On Mon, Oct 12, 2015 at 2:22 PM, Matt Turner  wrote:
>>> On Mon, Oct 12, 2015 at 11:12 AM, Rob Clark  wrote:
 On Mon, Oct 12, 2015 at 12:47 AM, Jason Ekstrand  
 wrote:
>>> +/**
>>> + * Convert a 2-byte half float to a 4-byte float.
>>> + * Based on code from:
>>> + * http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/008786.html
>>> + */
>>> +static inline float
>>> +_mesa_half_to_float(GLhalfARB val)
>>> +{
>>> +   return half_to_float(val);
>>> +}
>
> This is kind of ugly. How hard would it really be to just replace the uses
> with the new name?  I don't think its used *that* often.

 hmm, ~20-30 call sites.. not impossible to update them all, but I
 think it should be a separate patch and then drop the compat shims
 rather than one big patch that changes everything..

 We could also keep the _mesa_half_to_float() name.. but I really
 wanted to drop the GLhalfARB and not drag along GL typedefs.  If no
 one objects to just replacing GLhalfARB with uint16_t.

 I could go either way.
>>>
>>> Replacing GLhalfARB with uint16_t seems like a good plan.
>>
>> ok, then the most straightforward (least churn) approach seems to be
>> to keep the _mesa_ prefix but use uint16_t..
>>
>>> +
>>> +#include 
>>> +
>>> +#ifdef __cplusplus
>>> +extern "C" {
>>> +#endif
>>> +
>>> +uint16_t float_to_half(float val);
>>> +float half_to_float(uint16_t val);
>>
>> I think these functions need to be prefixed with something -- util_*
>> or something or just leave them as _mesa_*.
>
> Unfortunately, until is kind of a grab-bag right now.  Some stuff has a
> util_ prefix, some has kept its _mesa_ or u_ prefix depending on whether 
> it
> was copied from Mesa or gallium, and some (hash_table for example) isn't
> prefixed at all.  Personally, I'd go with either util_ (it is a utility
> library) or just keep _mesa_ (this is still the mesa project after all). 
> I'm
> not going to be too insistent though

 the util_ prefix conflicts w/ u_half.h (which appears to implement
 basically the same thing in a simpler way, but maybe not compatible
 enough to just switch to the gallium implementation?  Otherwise the
 easier approach would be to just move the gallium implementation to
 global util directory and use that instead)..  I was going to use
 convert_ prefix but that also conflicts..
>>>
>>> Seems valuable to ultimately remove the Gallium implementation as
>>> well. Chad did some really tedious work to improve the functions
>>> you're moving to round properly.
>>
>> hmm, looks like his change was mostly important for compiler (to match
>> what intel hw does).. otoh I guess it shouldn't hurt for gallum (which
>> looks to be used mostly for texture/format conversion) and would be
>> nice to de-duplicate..
>
> I'd be in favor of dropping this implementation over the gallium one,
> but not vice versa. I've expressed my concerns over this implementation
> before (it also looks more expensive), mainly rounding up float values
> to infinity half floats seems like a bad idea. The gallium
> implementation has a comment why I think is a bug, mostly because d3d10
> mandates such value getting rounded to MAX_HALF_FLOAT instead, gl not
> caring about it but at least recommending the same for converting to
> fp11 floats. I doubt hw in general rounds such values to infinity (due
> to the afromentioned d3d10 requirement, which is actually tested for).

well, I'll leave the gallium version as-is then..  I guess I can
understand where (for the using in compiler const propagation) there
is a desire to match what intel hw does (but otoh not really sure if
it matches what other hw does and if gl doesn't really care, not sure
how much that really matters).  But at least for now to clean up the
NIR dependency on GLSL I guess we should keep the current _mesa
version..

BR,
-R

> Roland
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

2015-10-12 Thread Roland Scheidegger

Am 12.10.2015 um 21:41 schrieb Roland Scheidegger:
> Am 12.10.2015 um 20:33 schrieb Rob Clark:
>> On Mon, Oct 12, 2015 at 2:22 PM, Matt Turner  wrote:
>>> On Mon, Oct 12, 2015 at 11:12 AM, Rob Clark  wrote:
 On Mon, Oct 12, 2015 at 12:47 AM, Jason Ekstrand  
 wrote:
>>> +/**
>>> + * Convert a 2-byte half float to a 4-byte float.
>>> + * Based on code from:
>>> + * http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/008786.html
>>> + */
>>> +static inline float
>>> +_mesa_half_to_float(GLhalfARB val)
>>> +{
>>> +   return half_to_float(val);
>>> +}
>
> This is kind of ugly. How hard would it really be to just replace the uses
> with the new name?  I don't think its used *that* often.

 hmm, ~20-30 call sites.. not impossible to update them all, but I
 think it should be a separate patch and then drop the compat shims
 rather than one big patch that changes everything..

 We could also keep the _mesa_half_to_float() name.. but I really
 wanted to drop the GLhalfARB and not drag along GL typedefs.  If no
 one objects to just replacing GLhalfARB with uint16_t.

 I could go either way.
>>>
>>> Replacing GLhalfARB with uint16_t seems like a good plan.
>>
>> ok, then the most straightforward (least churn) approach seems to be
>> to keep the _mesa_ prefix but use uint16_t..
>>
>>> +
>>> +#include 
>>> +
>>> +#ifdef __cplusplus
>>> +extern "C" {
>>> +#endif
>>> +
>>> +uint16_t float_to_half(float val);
>>> +float half_to_float(uint16_t val);
>>
>> I think these functions need to be prefixed with something -- util_*
>> or something or just leave them as _mesa_*.
>
> Unfortunately, until is kind of a grab-bag right now.  Some stuff has a
> util_ prefix, some has kept its _mesa_ or u_ prefix depending on whether 
> it
> was copied from Mesa or gallium, and some (hash_table for example) isn't
> prefixed at all.  Personally, I'd go with either util_ (it is a utility
> library) or just keep _mesa_ (this is still the mesa project after all). 
> I'm
> not going to be too insistent though

 the util_ prefix conflicts w/ u_half.h (which appears to implement
 basically the same thing in a simpler way, but maybe not compatible
 enough to just switch to the gallium implementation?  Otherwise the
 easier approach would be to just move the gallium implementation to
 global util directory and use that instead)..  I was going to use
 convert_ prefix but that also conflicts..
>>>
>>> Seems valuable to ultimately remove the Gallium implementation as
>>> well. Chad did some really tedious work to improve the functions
>>> you're moving to round properly.
>>
>> hmm, looks like his change was mostly important for compiler (to match
>> what intel hw does).. otoh I guess it shouldn't hurt for gallum (which
>> looks to be used mostly for texture/format conversion) and would be
>> nice to de-duplicate..
> 
> I'd be in favor of dropping this implementation over the gallium one,
> but not vice versa. I've expressed my concerns over this implementation
> before (it also looks more expensive), mainly rounding up float values
> to infinity half floats seems like a bad idea. The gallium
> implementation has a comment why I think is a bug, mostly because d3d10
> mandates such value getting rounded to MAX_HALF_FLOAT instead, gl not
> caring about it but at least recommending the same for converting to
> fp11 floats. I doubt hw in general rounds such values to infinity (due
> to the afromentioned d3d10 requirement, which is actually tested for).
> 
Albeit I have to say the rounding of the gallium implementation (outside
of clamping to non-infinite) isn't quite ideal neither - round to
nearest, away from zero if I see that right (this doesn't match d3d10
neither, which for float->float conversions requires round toward zero,
but unlike the infinity issue tests are ok with this).
So, I dunno how this should be handled. Maybe we really need two versions...

Roland

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

2015-10-12 Thread Roland Scheidegger

Am 12.10.2015 um 20:33 schrieb Rob Clark:
> On Mon, Oct 12, 2015 at 2:22 PM, Matt Turner  wrote:
>> On Mon, Oct 12, 2015 at 11:12 AM, Rob Clark  wrote:
>>> On Mon, Oct 12, 2015 at 12:47 AM, Jason Ekstrand  
>>> wrote:
>> +/**
>> + * Convert a 2-byte half float to a 4-byte float.
>> + * Based on code from:
>> + * http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/008786.html
>> + */
>> +static inline float
>> +_mesa_half_to_float(GLhalfARB val)
>> +{
>> +   return half_to_float(val);
>> +}

 This is kind of ugly. How hard would it really be to just replace the uses
 with the new name?  I don't think its used *that* often.
>>>
>>> hmm, ~20-30 call sites.. not impossible to update them all, but I
>>> think it should be a separate patch and then drop the compat shims
>>> rather than one big patch that changes everything..
>>>
>>> We could also keep the _mesa_half_to_float() name.. but I really
>>> wanted to drop the GLhalfARB and not drag along GL typedefs.  If no
>>> one objects to just replacing GLhalfARB with uint16_t.
>>>
>>> I could go either way.
>>
>> Replacing GLhalfARB with uint16_t seems like a good plan.
> 
> ok, then the most straightforward (least churn) approach seems to be
> to keep the _mesa_ prefix but use uint16_t..
> 
>> +
>> +#include 
>> +
>> +#ifdef __cplusplus
>> +extern "C" {
>> +#endif
>> +
>> +uint16_t float_to_half(float val);
>> +float half_to_float(uint16_t val);
>
> I think these functions need to be prefixed with something -- util_*
> or something or just leave them as _mesa_*.

 Unfortunately, until is kind of a grab-bag right now.  Some stuff has a
 util_ prefix, some has kept its _mesa_ or u_ prefix depending on whether it
 was copied from Mesa or gallium, and some (hash_table for example) isn't
 prefixed at all.  Personally, I'd go with either util_ (it is a utility
 library) or just keep _mesa_ (this is still the mesa project after all). 
 I'm
 not going to be too insistent though
>>>
>>> the util_ prefix conflicts w/ u_half.h (which appears to implement
>>> basically the same thing in a simpler way, but maybe not compatible
>>> enough to just switch to the gallium implementation?  Otherwise the
>>> easier approach would be to just move the gallium implementation to
>>> global util directory and use that instead)..  I was going to use
>>> convert_ prefix but that also conflicts..
>>
>> Seems valuable to ultimately remove the Gallium implementation as
>> well. Chad did some really tedious work to improve the functions
>> you're moving to round properly.
> 
> hmm, looks like his change was mostly important for compiler (to match
> what intel hw does).. otoh I guess it shouldn't hurt for gallum (which
> looks to be used mostly for texture/format conversion) and would be
> nice to de-duplicate..

I'd be in favor of dropping this implementation over the gallium one,
but not vice versa. I've expressed my concerns over this implementation
before (it also looks more expensive), mainly rounding up float values
to infinity half floats seems like a bad idea. The gallium
implementation has a comment why I think is a bug, mostly because d3d10
mandates such value getting rounded to MAX_HALF_FLOAT instead, gl not
caring about it but at least recommending the same for converting to
fp11 floats. I doubt hw in general rounds such values to infinity (due
to the afromentioned d3d10 requirement, which is actually tested for).

Roland


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

2015-10-12 Thread Roland Scheidegger

Am 12.10.2015 um 22:37 schrieb Rob Clark:
> On Mon, Oct 12, 2015 at 3:41 PM, Roland Scheidegger  
> wrote:
>> Am 12.10.2015 um 20:33 schrieb Rob Clark:
>>> On Mon, Oct 12, 2015 at 2:22 PM, Matt Turner  wrote:
 On Mon, Oct 12, 2015 at 11:12 AM, Rob Clark  wrote:
> On Mon, Oct 12, 2015 at 12:47 AM, Jason Ekstrand  
> wrote:
 +/**
 + * Convert a 2-byte half float to a 4-byte float.
 + * Based on code from:
 + * 
 https://urldefense.proofpoint.com/v2/url?u=http-3A__www.opengl.org_discussion-5Fboards_ubb_Forum3_HTML_008786.html=BQIBaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I=2SV7p2GaUU6_-p4UXWRZ9hppJQ1vlbvvFipu3TmlI7s=B2vMgNT8F0lMSh_aJLIvB2ErGZNaLSKmlOgEdZq7z9Y=
  
 + */
 +static inline float
 +_mesa_half_to_float(GLhalfARB val)
 +{
 +   return half_to_float(val);
 +}
>>
>> This is kind of ugly. How hard would it really be to just replace the 
>> uses
>> with the new name?  I don't think its used *that* often.
>
> hmm, ~20-30 call sites.. not impossible to update them all, but I
> think it should be a separate patch and then drop the compat shims
> rather than one big patch that changes everything..
>
> We could also keep the _mesa_half_to_float() name.. but I really
> wanted to drop the GLhalfARB and not drag along GL typedefs.  If no
> one objects to just replacing GLhalfARB with uint16_t.
>
> I could go either way.

 Replacing GLhalfARB with uint16_t seems like a good plan.
>>>
>>> ok, then the most straightforward (least churn) approach seems to be
>>> to keep the _mesa_ prefix but use uint16_t..
>>>
 +
 +#include 
 +
 +#ifdef __cplusplus
 +extern "C" {
 +#endif
 +
 +uint16_t float_to_half(float val);
 +float half_to_float(uint16_t val);
>>>
>>> I think these functions need to be prefixed with something -- util_*
>>> or something or just leave them as _mesa_*.
>>
>> Unfortunately, until is kind of a grab-bag right now.  Some stuff has a
>> util_ prefix, some has kept its _mesa_ or u_ prefix depending on whether 
>> it
>> was copied from Mesa or gallium, and some (hash_table for example) isn't
>> prefixed at all.  Personally, I'd go with either util_ (it is a utility
>> library) or just keep _mesa_ (this is still the mesa project after all). 
>> I'm
>> not going to be too insistent though
>
> the util_ prefix conflicts w/ u_half.h (which appears to implement
> basically the same thing in a simpler way, but maybe not compatible
> enough to just switch to the gallium implementation?  Otherwise the
> easier approach would be to just move the gallium implementation to
> global util directory and use that instead)..  I was going to use
> convert_ prefix but that also conflicts..

 Seems valuable to ultimately remove the Gallium implementation as
 well. Chad did some really tedious work to improve the functions
 you're moving to round properly.
>>>
>>> hmm, looks like his change was mostly important for compiler (to match
>>> what intel hw does).. otoh I guess it shouldn't hurt for gallum (which
>>> looks to be used mostly for texture/format conversion) and would be
>>> nice to de-duplicate..
>>
>> I'd be in favor of dropping this implementation over the gallium one,
>> but not vice versa. I've expressed my concerns over this implementation
>> before (it also looks more expensive), mainly rounding up float values
>> to infinity half floats seems like a bad idea. The gallium
>> implementation has a comment why I think is a bug, mostly because d3d10
>> mandates such value getting rounded to MAX_HALF_FLOAT instead, gl not
>> caring about it but at least recommending the same for converting to
>> fp11 floats. I doubt hw in general rounds such values to infinity (due
>> to the afromentioned d3d10 requirement, which is actually tested for).
> 
> well, I'll leave the gallium version as-is then..  I guess I can
> understand where (for the using in compiler const propagation) there
> is a desire to match what intel hw does (but otoh not really sure if
> it matches what other hw does and if gl doesn't really care, not sure
> how much that really matters).  But at least for now to clean up the
> NIR dependency on GLSL I guess we should keep the current _mesa
> version..

As far as I can tell (and I could easily be wrong here...) intel hw
doesn't have explicit conversion instruction, you just say it's a f16
destination. As such I believe the conversion used would just use
ordinary rounding mode, which is of course usually round to nearest even
(and the docs don't seem to mention it, but seems likely that too large
floats would get converted to infinities using that

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

2015-10-12 Thread Rob Clark

On Mon, Oct 12, 2015 at 6:07 PM, Roland Scheidegger  wrote:
> Am 12.10.2015 um 22:37 schrieb Rob Clark:
>> On Mon, Oct 12, 2015 at 3:41 PM, Roland Scheidegger  
>> wrote:
>>> Am 12.10.2015 um 20:33 schrieb Rob Clark:
 On Mon, Oct 12, 2015 at 2:22 PM, Matt Turner  wrote:
> On Mon, Oct 12, 2015 at 11:12 AM, Rob Clark  wrote:
>> On Mon, Oct 12, 2015 at 12:47 AM, Jason Ekstrand  
>> wrote:
> +/**
> + * Convert a 2-byte half float to a 4-byte float.
> + * Based on code from:
> + * 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.opengl.org_discussion-5Fboards_ubb_Forum3_HTML_008786.html=BQIBaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I=2SV7p2GaUU6_-p4UXWRZ9hppJQ1vlbvvFipu3TmlI7s=B2vMgNT8F0lMSh_aJLIvB2ErGZNaLSKmlOgEdZq7z9Y=
> + */
> +static inline float
> +_mesa_half_to_float(GLhalfARB val)
> +{
> +   return half_to_float(val);
> +}
>>>
>>> This is kind of ugly. How hard would it really be to just replace the 
>>> uses
>>> with the new name?  I don't think its used *that* often.
>>
>> hmm, ~20-30 call sites.. not impossible to update them all, but I
>> think it should be a separate patch and then drop the compat shims
>> rather than one big patch that changes everything..
>>
>> We could also keep the _mesa_half_to_float() name.. but I really
>> wanted to drop the GLhalfARB and not drag along GL typedefs.  If no
>> one objects to just replacing GLhalfARB with uint16_t.
>>
>> I could go either way.
>
> Replacing GLhalfARB with uint16_t seems like a good plan.

 ok, then the most straightforward (least churn) approach seems to be
 to keep the _mesa_ prefix but use uint16_t..

> +
> +#include 
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +uint16_t float_to_half(float val);
> +float half_to_float(uint16_t val);

 I think these functions need to be prefixed with something -- util_*
 or something or just leave them as _mesa_*.
>>>
>>> Unfortunately, until is kind of a grab-bag right now.  Some stuff has a
>>> util_ prefix, some has kept its _mesa_ or u_ prefix depending on 
>>> whether it
>>> was copied from Mesa or gallium, and some (hash_table for example) isn't
>>> prefixed at all.  Personally, I'd go with either util_ (it is a utility
>>> library) or just keep _mesa_ (this is still the mesa project after 
>>> all). I'm
>>> not going to be too insistent though
>>
>> the util_ prefix conflicts w/ u_half.h (which appears to implement
>> basically the same thing in a simpler way, but maybe not compatible
>> enough to just switch to the gallium implementation?  Otherwise the
>> easier approach would be to just move the gallium implementation to
>> global util directory and use that instead)..  I was going to use
>> convert_ prefix but that also conflicts..
>
> Seems valuable to ultimately remove the Gallium implementation as
> well. Chad did some really tedious work to improve the functions
> you're moving to round properly.

 hmm, looks like his change was mostly important for compiler (to match
 what intel hw does).. otoh I guess it shouldn't hurt for gallum (which
 looks to be used mostly for texture/format conversion) and would be
 nice to de-duplicate..
>>>
>>> I'd be in favor of dropping this implementation over the gallium one,
>>> but not vice versa. I've expressed my concerns over this implementation
>>> before (it also looks more expensive), mainly rounding up float values
>>> to infinity half floats seems like a bad idea. The gallium
>>> implementation has a comment why I think is a bug, mostly because d3d10
>>> mandates such value getting rounded to MAX_HALF_FLOAT instead, gl not
>>> caring about it but at least recommending the same for converting to
>>> fp11 floats. I doubt hw in general rounds such values to infinity (due
>>> to the afromentioned d3d10 requirement, which is actually tested for).
>>
>> well, I'll leave the gallium version as-is then..  I guess I can
>> understand where (for the using in compiler const propagation) there
>> is a desire to match what intel hw does (but otoh not really sure if
>> it matches what other hw does and if gl doesn't really care, not sure
>> how much that really matters).  But at least for now to clean up the
>> NIR dependency on GLSL I guess we should keep the current _mesa
>> version..
>
> As far as I can tell (and I could easily be wrong here...) intel hw
> doesn't have explicit conversion instruction, you just say it's a f16
> destination. As such I believe the conversion used would just use
> ordinary rounding mode,

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

2015-10-12 Thread Roland Scheidegger

Am 13.10.2015 um 01:01 schrieb Matt Turner:
> On Mon, Oct 12, 2015 at 3:07 PM, Roland Scheidegger  
> wrote:
>> As far as I can tell (and I could easily be wrong here...) intel hw
>> doesn't have explicit conversion instruction, you just say it's a f16
>> destination. As such I believe the conversion used would just use
>> ordinary rounding mode, which is of course usually round to nearest even
>> (and the docs don't seem to mention it, but seems likely that too large
>> floats would get converted to infinities using that mode). Rounding mode
>> is of course changeable (but would need to change it back after f32->f16
>> mov).
> 
> There's F32TO16/F16TO32 in Gen7 (IVB, HSW, VLV). The software routines
> were modified to match their behavior for constant propagation, as far
> as I know.
> 

Yes, I was looking at Broadwell, which can do the implicit conversion.
Regardless, I guess it works the same for both wrt rounding - you'd have
to change the rounding mode if you want round-to-zero as d3d10 requires
(I suspect that's exactly what the d3d driver does, since d3d11 f32tof16
instruction requires that too). Otherwise it's just
round-to-nearest-even which will round too large numbers to infinity.
(Albeit the docs don't quite seem to explicitly say default rounding
mode affects the half-float result of the f32tof16 instruction.)
But for GL any rounding is fine of course, and matching hw probably
makes sense.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

2015-10-12 Thread Matt Turner

On Mon, Oct 12, 2015 at 3:07 PM, Roland Scheidegger  wrote:
> As far as I can tell (and I could easily be wrong here...) intel hw
> doesn't have explicit conversion instruction, you just say it's a f16
> destination. As such I believe the conversion used would just use
> ordinary rounding mode, which is of course usually round to nearest even
> (and the docs don't seem to mention it, but seems likely that too large
> floats would get converted to infinities using that mode). Rounding mode
> is of course changeable (but would need to change it back after f32->f16
> mov).

There's F32TO16/F16TO32 in Gen7 (IVB, HSW, VLV). The software routines
were modified to match their behavior for constant propagation, as far
as I know.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

2015-10-12 Thread Roland Scheidegger

Am 13.10.2015 um 00:26 schrieb Rob Clark:
> On Mon, Oct 12, 2015 at 6:07 PM, Roland Scheidegger  
> wrote:
>> Am 12.10.2015 um 22:37 schrieb Rob Clark:
>>> On Mon, Oct 12, 2015 at 3:41 PM, Roland Scheidegger  
>>> wrote:
 Am 12.10.2015 um 20:33 schrieb Rob Clark:
> On Mon, Oct 12, 2015 at 2:22 PM, Matt Turner  wrote:
>> On Mon, Oct 12, 2015 at 11:12 AM, Rob Clark  wrote:
>>> On Mon, Oct 12, 2015 at 12:47 AM, Jason Ekstrand  
>>> wrote:
>> +/**
>> + * Convert a 2-byte half float to a 4-byte float.
>> + * Based on code from:
>> + * 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.opengl.org_discussion-5Fboards_ubb_Forum3_HTML_008786.html=BQIBaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I=2SV7p2GaUU6_-p4UXWRZ9hppJQ1vlbvvFipu3TmlI7s=B2vMgNT8F0lMSh_aJLIvB2ErGZNaLSKmlOgEdZq7z9Y=
>> + */
>> +static inline float
>> +_mesa_half_to_float(GLhalfARB val)
>> +{
>> +   return half_to_float(val);
>> +}

 This is kind of ugly. How hard would it really be to just replace the 
 uses
 with the new name?  I don't think its used *that* often.
>>>
>>> hmm, ~20-30 call sites.. not impossible to update them all, but I
>>> think it should be a separate patch and then drop the compat shims
>>> rather than one big patch that changes everything..
>>>
>>> We could also keep the _mesa_half_to_float() name.. but I really
>>> wanted to drop the GLhalfARB and not drag along GL typedefs.  If no
>>> one objects to just replacing GLhalfARB with uint16_t.
>>>
>>> I could go either way.
>>
>> Replacing GLhalfARB with uint16_t seems like a good plan.
>
> ok, then the most straightforward (least churn) approach seems to be
> to keep the _mesa_ prefix but use uint16_t..
>
>> +
>> +#include 
>> +
>> +#ifdef __cplusplus
>> +extern "C" {
>> +#endif
>> +
>> +uint16_t float_to_half(float val);
>> +float half_to_float(uint16_t val);
>
> I think these functions need to be prefixed with something -- util_*
> or something or just leave them as _mesa_*.

 Unfortunately, until is kind of a grab-bag right now.  Some stuff has a
 util_ prefix, some has kept its _mesa_ or u_ prefix depending on 
 whether it
 was copied from Mesa or gallium, and some (hash_table for example) 
 isn't
 prefixed at all.  Personally, I'd go with either util_ (it is a utility
 library) or just keep _mesa_ (this is still the mesa project after 
 all). I'm
 not going to be too insistent though
>>>
>>> the util_ prefix conflicts w/ u_half.h (which appears to implement
>>> basically the same thing in a simpler way, but maybe not compatible
>>> enough to just switch to the gallium implementation?  Otherwise the
>>> easier approach would be to just move the gallium implementation to
>>> global util directory and use that instead)..  I was going to use
>>> convert_ prefix but that also conflicts..
>>
>> Seems valuable to ultimately remove the Gallium implementation as
>> well. Chad did some really tedious work to improve the functions
>> you're moving to round properly.
>
> hmm, looks like his change was mostly important for compiler (to match
> what intel hw does).. otoh I guess it shouldn't hurt for gallum (which
> looks to be used mostly for texture/format conversion) and would be
> nice to de-duplicate..

 I'd be in favor of dropping this implementation over the gallium one,
 but not vice versa. I've expressed my concerns over this implementation
 before (it also looks more expensive), mainly rounding up float values
 to infinity half floats seems like a bad idea. The gallium
 implementation has a comment why I think is a bug, mostly because d3d10
 mandates such value getting rounded to MAX_HALF_FLOAT instead, gl not
 caring about it but at least recommending the same for converting to
 fp11 floats. I doubt hw in general rounds such values to infinity (due
 to the afromentioned d3d10 requirement, which is actually tested for).
>>>
>>> well, I'll leave the gallium version as-is then..  I guess I can
>>> understand where (for the using in compiler const propagation) there
>>> is a desire to match what intel hw does (but otoh not really sure if
>>> it matches what other hw does and if gl doesn't really care, not sure
>>> how much that really matters).  But at least for now to clean up the
>>> NIR dependency on GLSL I guess we should keep the current _mesa
>>> version..
>>
>> As far as I can tell (and I could easily be wrong here...) intel hw
>> doesn't have

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

2015-10-11 Thread Jason Ekstrand

On Oct 10, 2015 12:09 PM, "Matt Turner"  wrote:
>
> On Sat, Oct 10, 2015 at 11:47 AM, Rob Clark  wrote:
> > From: Rob Clark 
> >
> > Needed in NIR too, so move out of mesa/main/imports.c
> >
> > Signed-off-by: Rob Clark 
> > ---
> >  src/glsl/Makefile.am  |   1 +
> >  src/mesa/main/imports.c   | 148 --
> >  src/mesa/main/imports.h   |  38 --
> >  src/util/Makefile.sources |   2 +
> >  src/util/convert.c| 179
++
> >  src/util/convert.h|  43 +++
> >  6 files changed, 259 insertions(+), 152 deletions(-)
> >  create mode 100644 src/util/convert.c
> >  create mode 100644 src/util/convert.h
> >
> > diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am
> > index 3265391..347919b 100644
> > --- a/src/glsl/Makefile.am
> > +++ b/src/glsl/Makefile.am
> > @@ -160,6 +160,7 @@ glsl_compiler_SOURCES = \
> >  glsl_compiler_LDADD =  \
> > libglsl.la  \
> > $(top_builddir)/src/libglsl_util.la \
> > +   $(top_builddir)/src/util/libmesautil.la \
> > $(PTHREAD_LIBS)
> >
> >  glsl_test_SOURCES = \
> > diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c
> > index 350e675..230ebbc 100644
> > --- a/src/mesa/main/imports.c
> > +++ b/src/mesa/main/imports.c
> > @@ -307,154 +307,6 @@ _mesa_bitcount_64(uint64_t n)
> >  }
> >  #endif
> >
> > -
> > -/**
> > - * Convert a 4-byte float to a 2-byte half float.
> > - *
> > - * Not all float32 values can be represented exactly as a float16
value. We
> > - * round such intermediate float32 values to the nearest float16. When
the
> > - * float32 lies exactly between to float16 values, we round to the one
with
> > - * an even mantissa.
> > - *
> > - * This rounding behavior has several benefits:
> > - *   - It has no sign bias.
> > - *
> > - *   - It reproduces the behavior of real hardware: opcode F32TO16 in
Intel's
> > - * GPU ISA.
> > - *
> > - *   - By reproducing the behavior of the GPU (at least on Intel
hardware),
> > - * compile-time evaluation of constant packHalf2x16 GLSL
expressions will
> > - * result in the same value as if the expression were executed on
the GPU.
> > - */
> > -GLhalfARB
> > -_mesa_float_to_half(float val)
> > -{
> > -   const fi_type fi = {val};
> > -   const int flt_m = fi.i & 0x7f;
> > -   const int flt_e = (fi.i >> 23) & 0xff;
> > -   const int flt_s = (fi.i >> 31) & 0x1;
> > -   int s, e, m = 0;
> > -   GLhalfARB result;
> > -
> > -   /* sign bit */
> > -   s = flt_s;
> > -
> > -   /* handle special cases */
> > -   if ((flt_e == 0) && (flt_m == 0)) {
> > -  /* zero */
> > -  /* m = 0; - already set */
> > -  e = 0;
> > -   }
> > -   else if ((flt_e == 0) && (flt_m != 0)) {
> > -  /* denorm -- denorm float maps to 0 half */
> > -  /* m = 0; - already set */
> > -  e = 0;
> > -   }
> > -   else if ((flt_e == 0xff) && (flt_m == 0)) {
> > -  /* infinity */
> > -  /* m = 0; - already set */
> > -  e = 31;
> > -   }
> > -   else if ((flt_e == 0xff) && (flt_m != 0)) {
> > -  /* NaN */
> > -  m = 1;
> > -  e = 31;
> > -   }
> > -   else {
> > -  /* regular number */
> > -  const int new_exp = flt_e - 127;
> > -  if (new_exp < -14) {
> > - /* The float32 lies in the range (0.0, min_normal16) and is
rounded
> > -  * to a nearby float16 value. The result will be either zero,
subnormal,
> > -  * or normal.
> > -  */
> > - e = 0;
> > - m = _mesa_lroundevenf((1 << 24) * fabsf(fi.f));
> > -  }
> > -  else if (new_exp > 15) {
> > - /* map this value to infinity */
> > - /* m = 0; - already set */
> > - e = 31;
> > -  }
> > -  else {
> > - /* The float32 lies in the range
> > -  *   [min_normal16, max_normal16 + max_step16)
> > -  * and is rounded to a nearby float16 value. The result will
be
> > -  * either normal or infinite.
> > -  */
> > - e = new_exp + 15;
> > - m = _mesa_lroundevenf(flt_m / (float) (1 << 13));
> > -  }
> > -   }
> > -
> > -   assert(0 <= m && m <= 1024);
> > -   if (m == 1024) {
> > -  /* The float32 was rounded upwards into the range of the next
exponent,
> > -   * so bump the exponent. This correctly handles the case where
f32
> > -   * should be rounded up to float16 infinity.
> > -   */
> > -  ++e;
> > -  m = 0;
> > -   }
> > -
> > -   result = (s << 15) | (e << 10) | m;
> > -   return result;
> > -}
> > -
> > -
> > -/**
> > - * Convert a 2-byte half float to a 4-byte float.
> > - * Based on code from:
> > - * http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/008786.html
> > - */
> > -float
> > -_mesa_half_to_float(GLhalfARB val)
> > -{
> > -   /* XXX could also use

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

2015-10-10 Thread Rob Clark

On Sat, Oct 10, 2015 at 3:09 PM, Matt Turner  wrote:
> On Sat, Oct 10, 2015 at 11:47 AM, Rob Clark  wrote:
>> From: Rob Clark 
>>
>> Needed in NIR too, so move out of mesa/main/imports.c
>>
>> Signed-off-by: Rob Clark 
>> ---
>>  src/glsl/Makefile.am  |   1 +
>>  src/mesa/main/imports.c   | 148 --
>>  src/mesa/main/imports.h   |  38 --
>>  src/util/Makefile.sources |   2 +
>>  src/util/convert.c| 179 
>> ++
>>  src/util/convert.h|  43 +++
>>  6 files changed, 259 insertions(+), 152 deletions(-)
>>  create mode 100644 src/util/convert.c
>>  create mode 100644 src/util/convert.h
>>
>> diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am
>> index 3265391..347919b 100644
>> --- a/src/glsl/Makefile.am
>> +++ b/src/glsl/Makefile.am
>> @@ -160,6 +160,7 @@ glsl_compiler_SOURCES = \
>>  glsl_compiler_LDADD =  \
>> libglsl.la  \
>> $(top_builddir)/src/libglsl_util.la \
>> +   $(top_builddir)/src/util/libmesautil.la \
>> $(PTHREAD_LIBS)
>>
>>  glsl_test_SOURCES = \
>> diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c
>> index 350e675..230ebbc 100644
>> --- a/src/mesa/main/imports.c
>> +++ b/src/mesa/main/imports.c
>> @@ -307,154 +307,6 @@ _mesa_bitcount_64(uint64_t n)
>>  }
>>  #endif
>>
>> -
>> -/**
>> - * Convert a 4-byte float to a 2-byte half float.
>> - *
>> - * Not all float32 values can be represented exactly as a float16 value. We
>> - * round such intermediate float32 values to the nearest float16. When the
>> - * float32 lies exactly between to float16 values, we round to the one with
>> - * an even mantissa.
>> - *
>> - * This rounding behavior has several benefits:
>> - *   - It has no sign bias.
>> - *
>> - *   - It reproduces the behavior of real hardware: opcode F32TO16 in 
>> Intel's
>> - * GPU ISA.
>> - *
>> - *   - By reproducing the behavior of the GPU (at least on Intel hardware),
>> - * compile-time evaluation of constant packHalf2x16 GLSL expressions 
>> will
>> - * result in the same value as if the expression were executed on the 
>> GPU.
>> - */
>> -GLhalfARB
>> -_mesa_float_to_half(float val)
>> -{
>> -   const fi_type fi = {val};
>> -   const int flt_m = fi.i & 0x7f;
>> -   const int flt_e = (fi.i >> 23) & 0xff;
>> -   const int flt_s = (fi.i >> 31) & 0x1;
>> -   int s, e, m = 0;
>> -   GLhalfARB result;
>> -
>> -   /* sign bit */
>> -   s = flt_s;
>> -
>> -   /* handle special cases */
>> -   if ((flt_e == 0) && (flt_m == 0)) {
>> -  /* zero */
>> -  /* m = 0; - already set */
>> -  e = 0;
>> -   }
>> -   else if ((flt_e == 0) && (flt_m != 0)) {
>> -  /* denorm -- denorm float maps to 0 half */
>> -  /* m = 0; - already set */
>> -  e = 0;
>> -   }
>> -   else if ((flt_e == 0xff) && (flt_m == 0)) {
>> -  /* infinity */
>> -  /* m = 0; - already set */
>> -  e = 31;
>> -   }
>> -   else if ((flt_e == 0xff) && (flt_m != 0)) {
>> -  /* NaN */
>> -  m = 1;
>> -  e = 31;
>> -   }
>> -   else {
>> -  /* regular number */
>> -  const int new_exp = flt_e - 127;
>> -  if (new_exp < -14) {
>> - /* The float32 lies in the range (0.0, min_normal16) and is rounded
>> -  * to a nearby float16 value. The result will be either zero, 
>> subnormal,
>> -  * or normal.
>> -  */
>> - e = 0;
>> - m = _mesa_lroundevenf((1 << 24) * fabsf(fi.f));
>> -  }
>> -  else if (new_exp > 15) {
>> - /* map this value to infinity */
>> - /* m = 0; - already set */
>> - e = 31;
>> -  }
>> -  else {
>> - /* The float32 lies in the range
>> -  *   [min_normal16, max_normal16 + max_step16)
>> -  * and is rounded to a nearby float16 value. The result will be
>> -  * either normal or infinite.
>> -  */
>> - e = new_exp + 15;
>> - m = _mesa_lroundevenf(flt_m / (float) (1 << 13));
>> -  }
>> -   }
>> -
>> -   assert(0 <= m && m <= 1024);
>> -   if (m == 1024) {
>> -  /* The float32 was rounded upwards into the range of the next 
>> exponent,
>> -   * so bump the exponent. This correctly handles the case where f32
>> -   * should be rounded up to float16 infinity.
>> -   */
>> -  ++e;
>> -  m = 0;
>> -   }
>> -
>> -   result = (s << 15) | (e << 10) | m;
>> -   return result;
>> -}
>> -
>> -
>> -/**
>> - * Convert a 2-byte half float to a 4-byte float.
>> - * Based on code from:
>> - * http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/008786.html
>> - */
>> -float
>> -_mesa_half_to_float(GLhalfARB val)
>> -{
>> -   /* XXX could also use a 64K-entry lookup table */
>> -   const int m = val & 0x3ff;
>> -   const int e = (val >> 10) & 0x1f;
>> -

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

2015-10-10 Thread Matt Turner

On Sat, Oct 10, 2015 at 11:47 AM, Rob Clark  wrote:
> From: Rob Clark 
>
> Needed in NIR too, so move out of mesa/main/imports.c
>
> Signed-off-by: Rob Clark 
> ---
>  src/glsl/Makefile.am  |   1 +
>  src/mesa/main/imports.c   | 148 --
>  src/mesa/main/imports.h   |  38 --
>  src/util/Makefile.sources |   2 +
>  src/util/convert.c| 179 
> ++
>  src/util/convert.h|  43 +++
>  6 files changed, 259 insertions(+), 152 deletions(-)
>  create mode 100644 src/util/convert.c
>  create mode 100644 src/util/convert.h
>
> diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am
> index 3265391..347919b 100644
> --- a/src/glsl/Makefile.am
> +++ b/src/glsl/Makefile.am
> @@ -160,6 +160,7 @@ glsl_compiler_SOURCES = \
>  glsl_compiler_LDADD =  \
> libglsl.la  \
> $(top_builddir)/src/libglsl_util.la \
> +   $(top_builddir)/src/util/libmesautil.la \
> $(PTHREAD_LIBS)
>
>  glsl_test_SOURCES = \
> diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c
> index 350e675..230ebbc 100644
> --- a/src/mesa/main/imports.c
> +++ b/src/mesa/main/imports.c
> @@ -307,154 +307,6 @@ _mesa_bitcount_64(uint64_t n)
>  }
>  #endif
>
> -
> -/**
> - * Convert a 4-byte float to a 2-byte half float.
> - *
> - * Not all float32 values can be represented exactly as a float16 value. We
> - * round such intermediate float32 values to the nearest float16. When the
> - * float32 lies exactly between to float16 values, we round to the one with
> - * an even mantissa.
> - *
> - * This rounding behavior has several benefits:
> - *   - It has no sign bias.
> - *
> - *   - It reproduces the behavior of real hardware: opcode F32TO16 in Intel's
> - * GPU ISA.
> - *
> - *   - By reproducing the behavior of the GPU (at least on Intel hardware),
> - * compile-time evaluation of constant packHalf2x16 GLSL expressions will
> - * result in the same value as if the expression were executed on the 
> GPU.
> - */
> -GLhalfARB
> -_mesa_float_to_half(float val)
> -{
> -   const fi_type fi = {val};
> -   const int flt_m = fi.i & 0x7f;
> -   const int flt_e = (fi.i >> 23) & 0xff;
> -   const int flt_s = (fi.i >> 31) & 0x1;
> -   int s, e, m = 0;
> -   GLhalfARB result;
> -
> -   /* sign bit */
> -   s = flt_s;
> -
> -   /* handle special cases */
> -   if ((flt_e == 0) && (flt_m == 0)) {
> -  /* zero */
> -  /* m = 0; - already set */
> -  e = 0;
> -   }
> -   else if ((flt_e == 0) && (flt_m != 0)) {
> -  /* denorm -- denorm float maps to 0 half */
> -  /* m = 0; - already set */
> -  e = 0;
> -   }
> -   else if ((flt_e == 0xff) && (flt_m == 0)) {
> -  /* infinity */
> -  /* m = 0; - already set */
> -  e = 31;
> -   }
> -   else if ((flt_e == 0xff) && (flt_m != 0)) {
> -  /* NaN */
> -  m = 1;
> -  e = 31;
> -   }
> -   else {
> -  /* regular number */
> -  const int new_exp = flt_e - 127;
> -  if (new_exp < -14) {
> - /* The float32 lies in the range (0.0, min_normal16) and is rounded
> -  * to a nearby float16 value. The result will be either zero, 
> subnormal,
> -  * or normal.
> -  */
> - e = 0;
> - m = _mesa_lroundevenf((1 << 24) * fabsf(fi.f));
> -  }
> -  else if (new_exp > 15) {
> - /* map this value to infinity */
> - /* m = 0; - already set */
> - e = 31;
> -  }
> -  else {
> - /* The float32 lies in the range
> -  *   [min_normal16, max_normal16 + max_step16)
> -  * and is rounded to a nearby float16 value. The result will be
> -  * either normal or infinite.
> -  */
> - e = new_exp + 15;
> - m = _mesa_lroundevenf(flt_m / (float) (1 << 13));
> -  }
> -   }
> -
> -   assert(0 <= m && m <= 1024);
> -   if (m == 1024) {
> -  /* The float32 was rounded upwards into the range of the next exponent,
> -   * so bump the exponent. This correctly handles the case where f32
> -   * should be rounded up to float16 infinity.
> -   */
> -  ++e;
> -  m = 0;
> -   }
> -
> -   result = (s << 15) | (e << 10) | m;
> -   return result;
> -}
> -
> -
> -/**
> - * Convert a 2-byte half float to a 4-byte float.
> - * Based on code from:
> - * http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/008786.html
> - */
> -float
> -_mesa_half_to_float(GLhalfARB val)
> -{
> -   /* XXX could also use a 64K-entry lookup table */
> -   const int m = val & 0x3ff;
> -   const int e = (val >> 10) & 0x1f;
> -   const int s = (val >> 15) & 0x1;
> -   int flt_m, flt_e, flt_s;
> -   fi_type fi;
> -   float result;
> -
> -   /* sign bit */
> -   flt_s = s;
> -
> -   /* handle special cases */
> -   if ((e == 0) && (m == 0)) {
> -  /* zero */
>

[Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

2015-10-10 Thread Rob Clark

From: Rob Clark 

Needed in NIR too, so move out of mesa/main/imports.c

Signed-off-by: Rob Clark 
---
 src/glsl/Makefile.am  |   1 +
 src/mesa/main/imports.c   | 148 --
 src/mesa/main/imports.h   |  38 --
 src/util/Makefile.sources |   2 +
 src/util/convert.c| 179 ++
 src/util/convert.h|  43 +++
 6 files changed, 259 insertions(+), 152 deletions(-)
 create mode 100644 src/util/convert.c
 create mode 100644 src/util/convert.h

diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am
index 3265391..347919b 100644
--- a/src/glsl/Makefile.am
+++ b/src/glsl/Makefile.am
@@ -160,6 +160,7 @@ glsl_compiler_SOURCES = \
 glsl_compiler_LDADD =  \
libglsl.la  \
$(top_builddir)/src/libglsl_util.la \
+   $(top_builddir)/src/util/libmesautil.la \
$(PTHREAD_LIBS)
 
 glsl_test_SOURCES = \
diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c
index 350e675..230ebbc 100644
--- a/src/mesa/main/imports.c
+++ b/src/mesa/main/imports.c
@@ -307,154 +307,6 @@ _mesa_bitcount_64(uint64_t n)
 }
 #endif
 
-
-/**
- * Convert a 4-byte float to a 2-byte half float.
- *
- * Not all float32 values can be represented exactly as a float16 value. We
- * round such intermediate float32 values to the nearest float16. When the
- * float32 lies exactly between to float16 values, we round to the one with
- * an even mantissa.
- *
- * This rounding behavior has several benefits:
- *   - It has no sign bias.
- *
- *   - It reproduces the behavior of real hardware: opcode F32TO16 in Intel's
- * GPU ISA.
- *
- *   - By reproducing the behavior of the GPU (at least on Intel hardware),
- * compile-time evaluation of constant packHalf2x16 GLSL expressions will
- * result in the same value as if the expression were executed on the GPU.
- */
-GLhalfARB
-_mesa_float_to_half(float val)
-{
-   const fi_type fi = {val};
-   const int flt_m = fi.i & 0x7f;
-   const int flt_e = (fi.i >> 23) & 0xff;
-   const int flt_s = (fi.i >> 31) & 0x1;
-   int s, e, m = 0;
-   GLhalfARB result;
-   
-   /* sign bit */
-   s = flt_s;
-
-   /* handle special cases */
-   if ((flt_e == 0) && (flt_m == 0)) {
-  /* zero */
-  /* m = 0; - already set */
-  e = 0;
-   }
-   else if ((flt_e == 0) && (flt_m != 0)) {
-  /* denorm -- denorm float maps to 0 half */
-  /* m = 0; - already set */
-  e = 0;
-   }
-   else if ((flt_e == 0xff) && (flt_m == 0)) {
-  /* infinity */
-  /* m = 0; - already set */
-  e = 31;
-   }
-   else if ((flt_e == 0xff) && (flt_m != 0)) {
-  /* NaN */
-  m = 1;
-  e = 31;
-   }
-   else {
-  /* regular number */
-  const int new_exp = flt_e - 127;
-  if (new_exp < -14) {
- /* The float32 lies in the range (0.0, min_normal16) and is rounded
-  * to a nearby float16 value. The result will be either zero, 
subnormal,
-  * or normal.
-  */
- e = 0;
- m = _mesa_lroundevenf((1 << 24) * fabsf(fi.f));
-  }
-  else if (new_exp > 15) {
- /* map this value to infinity */
- /* m = 0; - already set */
- e = 31;
-  }
-  else {
- /* The float32 lies in the range
-  *   [min_normal16, max_normal16 + max_step16)
-  * and is rounded to a nearby float16 value. The result will be
-  * either normal or infinite.
-  */
- e = new_exp + 15;
- m = _mesa_lroundevenf(flt_m / (float) (1 << 13));
-  }
-   }
-
-   assert(0 <= m && m <= 1024);
-   if (m == 1024) {
-  /* The float32 was rounded upwards into the range of the next exponent,
-   * so bump the exponent. This correctly handles the case where f32
-   * should be rounded up to float16 infinity.
-   */
-  ++e;
-  m = 0;
-   }
-
-   result = (s << 15) | (e << 10) | m;
-   return result;
-}
-
-
-/**
- * Convert a 2-byte half float to a 4-byte float.
- * Based on code from:
- * http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/008786.html
- */
-float
-_mesa_half_to_float(GLhalfARB val)
-{
-   /* XXX could also use a 64K-entry lookup table */
-   const int m = val & 0x3ff;
-   const int e = (val >> 10) & 0x1f;
-   const int s = (val >> 15) & 0x1;
-   int flt_m, flt_e, flt_s;
-   fi_type fi;
-   float result;
-
-   /* sign bit */
-   flt_s = s;
-
-   /* handle special cases */
-   if ((e == 0) && (m == 0)) {
-  /* zero */
-  flt_m = 0;
-  flt_e = 0;
-   }
-   else if ((e == 0) && (m != 0)) {
-  /* denorm -- denorm half will fit in non-denorm single */
-  const float half_denorm = 1.0f / 16384.0f; /* 2^-14 */
-  float mantissa = ((float) (m)) / 1024.0f;
-  float sign = s ? -1.0f : 1.0f;
-  return sign * mantissa * half_denorm;
-   }
-   else if ((e == 31) && (m ==

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

Re: [Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

[Mesa-dev] [PATCH 3/6] glsl: move half<->float convertion to util

15 matches

Site Navigation

Mail list logo

Footer information