View mode: basic / threaded / horizontal-split · Log in · Help
November 20, 2012
Re: half datatype?
On 18/11/12 12:21, Manu wrote:
> I've often wondered about having an official 'half' type.
> It's very common in rendering/image processing, supported by most video
> cards (so compression routines interacting with this type are common),
> and it's also supported in hardware by some cpu's.
> ARM for instance supports 'half's in hardware, and GCC has an __fp16
> type which would map nicely if D supported the type in the front end.
> The alternative us to use ushort everywhere, which is awkward, because
> it is neither unsigned, nor is it an integer, and it's not typesafe
> (allows direct assignment to ints and stuff)...
> It would be nice if: cast(half)someFloat would yield the proper value,
> even if it is performed in software in most architectures, it could be
> mapped to hardware for those that do it.
> It could be done in a library, but then GCC couldn't map it properly to
> the hardware type, and since D has no way to describe implicit casts
> (that I know of?) it becomes awkward to use.
> someFloat = someHalf <- doesn't work, because a cast operator expects an
> explicit cast, even though this is a lossless conversion and should be
> exactly the same as someDouble = someFloat.
> Thoughts?

I suspect that what you want in nearly all cases is conversion from

half[] <-> float[]

ie, a pack/unpack operation. I think it would be quite rare to want to 
operate on a single half.

Although it's supported natively on GPUs, for D's purposes it is more 
natural to view it as compressed data.
November 20, 2012
Re: half datatype?
On 20 November 2012 09:41, Jacob Carlborg <> wrote:

> On 2012-11-20 01:45, Manu wrote:
>> On 19 November 2012 22:28, Rob T < <>>
>> wrote:
>>     On Monday, 19 November 2012 at 19:14:43 UTC, Jonathan M Davis wrote:
>>         I'd never even _heard_ of half types before this discussion came
>>         up. But then
>>         again, the same goes for SIMD. And IIRC, there was some sort of
>>         function
>>         attribute relating to pointers and registers that you or some
>>         other gaming
>>         person was insisting on a while back, and I'd never heard of it
>>         existing in
>>         C++ either (as an extension or otherwise). You clearly program
>>         in a very
>>         different world than I do. I care about high performance in what
>>         I do but
>>         nothing on _that_ level. I suspect that this is another one of
>>         those things
>>         that certain folks would really like to have, and most of the
>>         rest of us don't
>>         have any real interest in and often know nothing about in the
>>         first place. I
>>         don't know that I really care whether it's added to the language
>>         though. I'll
>>         leave that sort of decision up to Walter.
>>         If anything, I just find it interesting how many low level
>>         things folks like
>>         you keep coming up with as must-haves or very strong wants that
>>         I've never
>>         even heard of and will almost certainly never care about aside
>>         perhaps from
>>         how having them in D might help D catch on.
>>         - Jonathan M Davis
>>     Anyone interested in the low precision float types, and what they
>>     are good for, can start here
>>     <**Small_Float_Formats<>
>> >
>>     I did not read through all of this thread, but my guess is that the
>>     people making the request for half float are mostly into game
>>     development and image processing.
>>     When I first started investigating D as a potential C++ replacement,
>>     I noted that a lot of the "visible" development (what I could see
>>     being publicized) was game development, so it seemed that for some
>>     reason a lot of the D users were also game developers, so there's
>>     perhaps something about D that they find attractive.
>> I've said it before, but I think D has MASSIVE potential in gaming. We
>> are an industry crying our for salvation from C++, but there's no
>> possibility to compromise on the level of access it provides us to the
>> hardware we work with.
>> D is the only language I know of that seriously threatens to offer
>> modern programming constructs, while still providing a syntax and
>> compiler technology that I can easily understand in terms of code
>> generation and can hit the metal when I need to.
>> Additionally, most games programmers have very long-term relationships
>> with C++ almost exclusively, so despite hating it, moving to something
>> utterly different like rust or whatever cool thing comes along will just
>> never fly. You'll never convince a team of 10-30 programmers to agree on
>> such a change all at once, and re-training staff in something so foreign
>> would never be economical.
>> D is again particularly interesting here because it's enough like C++
>> and C# that programmers feel immediately comfortable and somewhat
>> liberated, but not threatened. Also, in a lot of cases, the changes to D
>> are relatively intuitive. The things you expect should work, often just
>> do... but there are still lots of rough edges too.
>> Gaming is a very demanding and progressive field of software, but also
>> very backwards at the same time. It's a sort of unity between many
>> disciplines, and it all comes together under a performance critical and
>> usually embedded umbrella, in a highly competitive and fickle industry.
>> You can't tell the customer to upgrade their hardware when it needs to
>> run on a console with an ~8 year lifecycle. As a (tech/engine)
>> programmer, if you don't scrutinise the code generation, calling
>> conventions, memory access patterns, data layout and sizes, the
>> competition will, and their product will appear superior. Towards the
>> end of that 8 year cycle, programmers are REALLY squeezing these
>> machines. If the language doesn't support that, then you can't compete
>> anymore, hence we remain stuck on C++ (and there are many instances
>> where the industry is reverting to C because C++ is a bloaty pig).
>>     Why game devs are interested so much in D is interesting considering
>>     the GC is noted to be a problem for game devs. The work of H. S.
>>     Teoh comes to mind with his work on a game engine, that pushed the
>>     limits of the GC and std lib.
>> I'll admit this is my biggest fear hands down!
>> That said, D is the only GC based language I know if where the GC is
>> relatively optional. This allows us to hedge our bets, and ease in to it
>> slowly as we gain confidence and understanding of how it behaves.
>> I don't yet have much confidence in the GC, and generally avoid using
>> it. I only use it for short term allocations, or non-critical-loop work
>> which often only survive for the scope of the function.
> Someone has created GC free versions of Phobos and druntime:

Nice case study! Thanks!
Looks like a cool little game too :P

> Was posted here:
> --
> /Jacob Carlborg
November 20, 2012
Re: half datatype?
On Tuesday, 20 November 2012 at 09:11:07 UTC, Manu wrote:
> Nice case study! Thanks!
> Looks like a cool little game too :P

 Watched the video. Interesting looking game, but how long it was 
taking to move around the ships gives a sense of size, making me 
ask myself 'my god, how big IS that ship?'.
November 20, 2012
Re: half datatype?
I've used half in C++, although mostly just to feed to the GPU 
since its pretty common that you don't want to waste the 
bandwidth on 32 bit floats.
November 21, 2012
Re: half datatype?
On Tuesday, 20 November 2012 at 09:11:07 UTC, Manu wrote:
> Nice case study! Thanks!
> Looks like a cool little game too :P

AFAIK, tart also has a prototype of realtime GC, but I don't know 
whether it can solve your problem. Such things are of little 
priority now for D and general purpose programming, I think.
Next ›   Last »
1 2 3 4
Top | Discussion index | About this forum | D home