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
next sibling 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 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 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
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