November 20, 2012 Re: half datatype? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg Attachments:
| On 20 November 2012 09:41, Jacob Carlborg <doob@me.com> wrote: > On 2012-11-20 01:45, Manu wrote: > >> On 19 November 2012 22:28, Rob T <rob@ucora.com <mailto:rob@ucora.com>> >> >> 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 >> http://www.opengl.org/wiki/__**Small_Float_Formats<http://www.opengl.org/wiki/__Small_Float_Formats> >> >> <http://www.opengl.org/wiki/**Small_Float_Formats<http://www.opengl.org/wiki/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: > > http://3d.benjamin-thaut.de/?**p=20#more-20<http://3d.benjamin-thaut.de/?p=20#more-20> Nice case study! Thanks! Looks like a cool little game too :P > Was posted here: > > http://forum.dlang.org/thread/**k27bh7$t7f$1@digitalmars.com<http://forum.dlang.org/thread/k27bh7$t7f$1@digitalmars.com> > > -- > /Jacob Carlborg > |
November 20, 2012 Re: half datatype? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Era Scarecrow | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | 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.
|
Copyright © 1999-2021 by the D Language Foundation