November 20, 2012
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
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
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
 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
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