www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GPU/CPU roadmaps

reply bearophile <bearophileHUGS lycos.com> writes:
D2/D3 may become a good language to create video games, this is a new
interesting document that shows some of the things D2 users may want to use it
for:
http://graphics.cs.williams.edu/archive/SweeneyHPG2009/TimHPG2009.pdf

I don't know how D2 can adapt itself to help in such regards.

Bye,
bearophile
Aug 10 2009
next sibling parent reply davidl <davidl nospam.org> writes:
在 Tue, 11 Aug 2009 08:54:07 +0800，bearophile <bearophileHUGS lycos.com>  
写道:


 D2/D3 may become a good language to create video games, this is a new  
 interesting document that shows some of the things D2 users may want to  
 use it for:
 http://graphics.cs.williams.edu/archive/SweeneyHPG2009/TimHPG2009.pdf

 I don't know how D2 can adapt itself to help in such regards.

 Bye,
 bearophile


At the first sight, I thought that guy were insane to abandon the merit of  
current GPU computing. Then, when I went through the slice of productivity  
is vital. I think I'm completely convinced by this exact point.
GPU programming and blending into games is pretty specialized skill for  
programmers. Maybe 1 of 1000 programmers has this skill. And maybe 1 of 2  
has the sufficient knowledge to handle it well.
I would expect an easier development model.

-- 
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
Aug 10 2009
parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
davidl Wrote:


 在 Tue, 11 Aug 2009 08:54:07 +0800，bearophile <bearophileHUGS lycos.com>  
 写道:
 

 D2/D3 may become a good language to create video games, this is a new  
 interesting document that shows some of the things D2 users may want to  
 use it for:
 http://graphics.cs.williams.edu/archive/SweeneyHPG2009/TimHPG2009.pdf

 I don't know how D2 can adapt itself to help in such regards.

 Bye,
 bearophile


 
 At the first sight, I thought that guy were insane to abandon the merit of  
 current GPU computing. Then, when I went through the slice of productivity  
 is vital. I think I'm completely convinced by this exact point.
 GPU programming and blending into games is pretty specialized skill for  
 programmers. Maybe 1 of 1000 programmers has this skill. And maybe 1 of 2  
 has the sufficient knowledge to handle it well.
 I would expect an easier development model.
 
 -- 
 使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/


Sweeney makes some strong points in his presentation, it's true that the line
between CPU and GPU is growing thinner and thinner,  and GPU programming is not
the easiest thing to learn. I had an easier time learning ASM than I did
learning the GPU pipeline in OpenGL heh. However it's just like everything
else, its much harder to learn it than to use it once you get the hang of it.

The D language definitely has what it takes to fully exploit the concepts of
this presentation, most of what he mentions about the language and compiler are
either already covered by D or are being talked about.

I wouldn't be surprised to see major games releases built in D in a few years.
Aug 10 2009
next sibling parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Jeremie Pelletier wrote:

 
 Sweeney makes some strong points in his presentation, it's true that the line
between CPU and GPU is growing thinner and thinner,  and GPU programming is not
the easiest thing to learn. I had an easier time learning ASM than I did
learning the GPU pipeline in OpenGL heh. However it's just like everything
else, its much harder to learn it than to use it once you get the hang of it.
 
 The D language definitely has what it takes to fully exploit the concepts of
this presentation, most of what he mentions about the language and compiler are
either already covered by D or are being talked about.
 
 I wouldn't be surprised to see major games releases built in D in a few years.


I'd love to see that, though I worry that the existing C++ codebase
(mostly in middleware) is too momentous.  It's like garbage trucks on ice.

But man, with the scale the game industry works on, it'd totally be
worth their while.  They'd be able to halve their coder population and
use the other half to write new libraries in D.  Once that's done the
other half can be used to make more games or make games more awesome.
Convincing them of this is another story :/
Aug 10 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Chad J:


I'd love to see that, though I worry that the existing C++ codebase (mostly in
middleware) is too momentous.  It's like garbage trucks on ice.<


They spend lot of work and money on such code. I don't think they are so fixed
on C++. So I think they are willing to change languages (to D) if they see D as
good enough for their purposes.

They need a compiler able to produce efficient code (LDC is almost there), a
profiler, debugger, code coverage, a well debugged language. Some editor
support for D (a really good IDE isn't strictly necessary). First of all they
need a language that's able to do in a simple way what they need, this means
using Intel Larrabee efficiently and GPUs in a simple enough way. A language
that's not designed to replace scripting languages (like Lua, Python, etc) but
to work well beside them. A language that allows to use software transactional
memory in a handy way, and to use a lot of data parallelism instructions
efficiently and with a good enough syntax. A language that's safer, with less
corner cases and that allows to write concurrent code that's much less buggy
(here the type system helps a lot, like the non-nullability by defaulf of class
references).

Currently the D2 language isn't much designed for such things.
Give them such things and I think they are willing to leave C++ for D in a
short time :-)

Bye,
bearophile
Aug 11 2009
prev sibling parent reply language_fan <foo bar.com.invalid> writes:
Tue, 11 Aug 2009 00:37:46 -0400, Jeremie Pelletier thusly wrote:


 I wouldn't be surprised to see major games releases built in D in a few
 years.


It's quite optimistic to think that the toolchain will be usable and 
robust enough on the large scale in a few years. For instance adding the 
keywords immutable, const, and pure will not magically turn D into the 
state of the art research language in the category of pure functional 
languages.
Aug 11 2009
parent Jeremie Pelletier <jeremiep gmail.com> writes:
language_fan Wrote:


 Tue, 11 Aug 2009 00:37:46 -0400, Jeremie Pelletier thusly wrote:
 

 I wouldn't be surprised to see major games releases built in D in a few
 years.


 
 It's quite optimistic to think that the toolchain will be usable and 
 robust enough on the large scale in a few years. For instance adding the 
 keywords immutable, const, and pure will not magically turn D into the 
 state of the art research language in the category of pure functional 
 languages.


Yeah it's optimistic, but not unrealistic. Most of the concepts talked about in
the presentation are covered on Bartosz's blog, which I've been reading with
much interest in the past days, and will most likely end up in D sooner or
later.

From what I read of the presentation, functional programming is only a quarter
of his framework concept (dealing with physics and the likes), there is still
STM for game state, good old sequencial programming to talk to the hardware,
and then highly parallel vector processing.

For the moment libraries like OpenCL could be used to provide the vector
processing, and STM only requires a software implementation, it doesn't have to
be part of the language, because we don't want it everywhere (that 30%
performance overhead is scary).

As for the masses of libraries already available in C++, they can all be ported
to D, with less code, and performing more efficiently. 3rd party middleware
usually have a C API so its not a problem either.

Thats the beauty of abstractions, if we abstract OpenCL now for vector
processing, we can just replace this module in the future to use intel's
larrabee and all the code using the interface wouldn't see the difference.

So yeah, I'm optimistic, because I know its something we can start designing
right away, and thinking about things like that is exactly why I love
programming so much.
Aug 11 2009
prev sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
bearophile wrote:


 D2/D3 may become a good language to create video games, this is a new
 interesting document that shows some of the things D2 users may want to
 use it for:
 http://graphics.cs.williams.edu/archive/SweeneyHPG2009/TimHPG2009.pdf
 
 I don't know how D2 can adapt itself to help in such regards.
 
 Bye,
 bearophile


Do you think the D language needs to adapt more for this market? From my 
limited perspective, I see numerous things D does, especially in the 
concurrency department, that is on the list of requirements put forth in 
that presentation. 

Furthermore, it's interesting to note some of the numbers pertaining to GOW 
2: 250K LoC for the game and 2000K LoC for the engine, excluding loads of 
libraries like speedtree, openal, etc. So middleware is key right? 
Especially by providing easier ways to program difficult architectures. Now 
this again is something that D can do well, it's very suitable for building 
good libraries. 

Now here is the problem too, they have to be build. Concluding remark of the 
presentation says that if you start building an engine now, you finish in 
2014. I don't think D has a chance on this scale of game development when it 
faces competition from such monster engines in C++.

To return to your original question: what about the systems programming 
aspects of D? For example, cutting out the GC and typeinfo bloat, dealing 
with arrays, whatever. Is this something that good library developers can do 
just on their own or do we need some more support for this? I was thinking 
what it would take to develop a specialized component in D that can be used 
from within a demanding C/C++ ecosystem.
Aug 11 2009