www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Open GL Bindings (was Re: GPGPU Arrays)

reply Mikola Lysenko <mclysenk mtu.edu> writes:
Personally, I think that it would be a bad idea to jump in and add
language-level support for GPU specific functions.  The technology is just
changing so fast right now that any effort would probably be hopelessly
obsolete within a few months.

That said, I think it would be good to get OpenGL / GLSL bindings into the
standard library.  When it comes to graphics, these are basically standard
interfaces, and official library support would be huge.  They provide all the
basic facilities for handling GPGPU, without the built in expiration date. 
Besides, we could leverage the excellent work that has already been done by
Aldacron et.al.  Off the top of my head, I can think of a several benefits of
this approach:

1. Reduced set up hassle

Right now building derelict is a huge PITA.  I know that Derek Parnell and
Aldacron have worked an incredible amount on simplifying this process, but it
is hardly automatic.  On Linux, I need to check out the latest version of
derelict, download build, compile some set up scripts, add paths to my project,
link in libraries, try compiling, then go back and add that -op switch I
forgot, etc. etc.

Making OpenGL work out of the box saves a huge amount of time and agony. 
Imagine how wonderful life could be if all one had to do to was add:

import opengl.gl;

Which leads into my next point:

2.  Built in OpenGL is more newbie friendly

When it comes to attracting novice programmers, graphics are extremely
important.  Most neophyte coders are interested in making games and getting
things running around on the screen.  From personal experience, I can say that
this is how I learned how to program, and also how many of my friends picked up
the skill.  The importance of graphics in attracting and educating new users
can not be overstated.

One of the reasons Python has been so effective in hooking programmers is that
they have a robust set of graphics bindings which are easily available.  C# is
likewise popular because of its XNA game development framework.  Java has been
used in web games since the 1990s, with decent success.   Even C compilers come
with OpenGL bindings installed by default.  For newbies, graphics are much more
compelling then a terminal.

Which brings me to my final point;

3. OpenGL is standard

And it has been the standard for graphics since the early 90s.  It works on Mac
OS, Linux and even Windows.  Solaris has OpenGL support.  Even video game
consoles have OpenGL bindings these days.  In fact, if you include the last
category, there are probably more hardware units out there that have OpenGL
support than there are systems that support ANSI C-style FILE stream IO.

Due to its popularity, this interface is probably not going to change much in
the coming years.  Granted Khronos group and company are revamping the
specification, but it is doubtful that this will happen at the expense of
backwards compatibility.

Besides, Aldacron has basically worked out most of the details involved in
getting future-proofed OpenGL bindings up and running.  I'm sure it shouldn't
be too hard to work out some scheme for incorporating a stable version of
derelict into the main trunk of either Phobos and/or Tango.  The added
development overhead would be so low in comparison to the huge benefit for the
community.

Of course not every little feature should get library level support, but it
just seems bizarre that something so essential is only available via a third
party add on.  Granted, we also need GUI utilities and template containers, but
I suspect that both of these will come in time.

-Mik
Jul 11 2007
next sibling parent Clay Smith <clayasaurus gmail.com> writes:
Mikola Lysenko wrote:
 Personally, I think that it would be a bad idea to jump in and add
language-level support for GPU specific functions.  The technology is just
changing so fast right now that any effort would probably be hopelessly
obsolete within a few months.
 
 That said, I think it would be good to get OpenGL / GLSL bindings into the
standard library.  When it comes to graphics, these are basically standard
interfaces, and official library support would be huge.  They provide all the
basic facilities for handling GPGPU, without the built in expiration date. 
Besides, we could leverage the excellent work that has already been done by
Aldacron et.al.  Off the top of my head, I can think of a several benefits of
this approach:
 
 1. Reduced set up hassle

It would be nice to have OGL standard lib support, but not necessary IMO. For 1, just use DSSS.
 
 2.  Built in OpenGL is more newbie friendly
 

True... then again, OpenGL is kind of low level. A higher level lib would be even more newbie friendly, and will likely come with OGL bindings anyway.
 
 3. OpenGL is standard
 

I wouldn't mind seeing it, but it would put some stress on Walter and Mike to put through the major effort of keeping these bindings updated and working with the latest compiler and OpenGL versions. ~ Clay
Jul 11 2007
prev sibling next sibling parent Sebastian Beschke <s.beschke gmx.de> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Having OpenGL in the standard library is a neat idea; however, OpenGL
needs to interact with the window system. This means that you would need
to have some kind of window manager library inside the standard library,
too.
While that, too, would be neat, it would also bloat the standard library
and hinder the developer's freedom of choice. So I'm not sure if it's
worth it. Most people wanting to do some serious development with OpenGL
will need to set up a separate library (e.g. SDL/Derelict) along with it
anyway.

- -Sebastian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGlWsRKb/1n5A2TAMRArTOAJwKexUq5PIoxyUP1cdcuuQLclhmbwCeJuM1
8FhovItsh7psV0r7hGxBVVQ=
=Zwn2
-----END PGP SIGNATURE-----
Jul 11 2007
prev sibling next sibling parent reply Tristam MacDonald <swiftcoder gmail.com> writes:
Mikola Lysenko Wrote:

 That said, I think it would be good to get OpenGL / GLSL bindings into the
standard library.  When it comes to graphics, these are basically standard
interfaces, and official library support would be huge.  They provide all the
basic facilities for handling GPGPU, without the built in expiration date. 
Besides, we could leverage the excellent work that has already been done by
Aldacron et.al.  Off the top of my head, I can think of a several benefits of
this approach:
 
 1. Reduced set up hassle
 
 Right now building derelict is a huge PITA.  I know that Derek Parnell and
Aldacron have worked an incredible amount on simplifying this process, but it
is hardly automatic.  On Linux, I need to check out the latest version of
derelict, download build, compile some set up scripts, add paths to my project,
link in libraries, try compiling, then go back and add that -op switch I
forgot, etc. etc.
 
 Making OpenGL work out of the box saves a huge amount of time and agony. 
Imagine how wonderful life could be if all one had to do to was add:
 
 import opengl.gl;

So don't use derelict - I don't since I didn't want to port it to Mac. Honestly, all you need is a GL header file (run h2d on gl.h and do 5 minutes search & replace - or automate it in perl, whatever), and a platform context toolkit, such as GLFW or SDL, of which several are already around. Even better, grab the XML definition files from GLee (www.elf-stone.com), and build a generator script for D (I will do at some point, but haven't needed it yet as I am on Mac, and we have GL 2 in core).
 Which leads into my next point:
 
 2.  Built in OpenGL is more newbie friendly
 
 When it comes to attracting novice programmers, graphics are extremely
important.  Most neophyte coders are interested in making games and getting
things running around on the screen.  From personal experience, I can say that
this is how I learned how to program, and also how many of my friends picked up
the skill.  The importance of graphics in attracting and educating new users
can not be overstated.
 
 One of the reasons Python has been so effective in hooking programmers is that
they have a robust set of graphics bindings which are easily available.  C# is
likewise popular because of its XNA game development framework.  Java has been
used in web games since the 1990s, with decent success.   Even C compilers come
with OpenGL bindings installed by default.  For newbies, graphics are much more
compelling then a terminal.

Tried setting up PyGame on a Mac recently? Or any system for that matter? Newbie friendly I would not call it. I consider my 'installer foo' to be stronger than most and it took several hours to get the pre-built binaries working. I didn't even go near a source install.
 Which brings me to my final point;
 
 3. OpenGL is standard
 
 And it has been the standard for graphics since the early 90s.  It works on
Mac OS, Linux and even Windows.  Solaris has OpenGL support.  Even video game
consoles have OpenGL bindings these days.  In fact, if you include the last
category, there are probably more hardware units out there that have OpenGL
support than there are systems that support ANSI C-style FILE stream IO.
 
 Due to its popularity, this interface is probably not going to change much in
the coming years.  Granted Khronos group and company are revamping the
specification, but it is doubtful that this will happen at the expense of
backwards compatibility.
 
 Besides, Aldacron has basically worked out most of the details involved in
getting future-proofed OpenGL bindings up and running.  I'm sure it shouldn't
be too hard to work out some scheme for incorporating a stable version of
derelict into the main trunk of either Phobos and/or Tango.  The added
development overhead would be so low in comparison to the huge benefit for the
community.

Hang on, hang on! D isn't only a PC language is it? Don't forget all that embedded hardware that will never see an OpenGL implementation. Direct frame-buffer access would make more sense, but there are plenty of devices without that as well. And even if we only deal with PCs, OpenGL is not the only game in town (think Direct3D), and OpenGL is not really that standard... each console manufacturer rolls their own, with little regard for the core standard. Plus lets not forget OpenGL ES, for all those mobile phones, etc. And then of course there is the upcoming Khronos release, where OpenGL gets split into 'classic' and 'modern', with the fixed function pipeline going the way of the dinosaurs very quickly. And as far as future proofing, a lot can be done, but how do you deal with an API that has at times added extensions on a monthly basis?
 Of course not every little feature should get library level support, but it
just seems bizarre that something so essential is only available via a third
party add on.  Granted, we also need GUI utilities and template containers, but
I suspect that both of these will come in time.
 
 -Mik

I would say templated-containers are desperately needed, before everyone rolls their own non-compatible versions. But GUI stuff (and I include OpenGL) in the core library? That requires unified cross-platform GUI toolkits, and I don't really think you will find anyone willing to invest a few million man-hours in that can of worms. What is wrong with just using wxD or similar, rather than polluting the standard lib?
Jul 11 2007
next sibling parent Mikola Lysenko <mclysenk mtu.edu> writes:
Tristam MacDonald Wrote:

 I would say templated-containers are desperately needed, before everyone rolls
their own non-compatible versions. But GUI stuff (and I include OpenGL) in the
core library? That requires unified cross-platform GUI toolkits, and I don't
really think you will find anyone willing to invest a few million man-hours in
that can of worms. What is wrong with just using wxD or similar, rather than
polluting the standard lib?
 

You have a good point. I guess I was a bit frustrated after spending several hours trying to port some derelict to code to my Mac, and I just felt like ranting a bit. Ultimately, it is not really fair to compare D and C in this category, since for the onus for portability falls upon the OpenGL developers - not the C standard. Ultimately, putting OpenGL support directly in D is probably a bit too short-sighted, when it comes right down to it. That said, I think it would be nice if getting these things set up was a bit easier and consistent. Right now D OpenGL programs are hardly what one could call portable. I find that my old code is usually so damn brittle, that there is little point in redistributing it or even saving it from one month to the next. -Mik
Jul 11 2007
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Tristam MacDonald wrote:

 So don't use derelict - I don't since I didn't want to port it to
 Mac. Honestly, all you need is a GL header file (run h2d on gl.h and
 do 5 minutes search & replace - or automate it in perl, whatever),
 and a platform context toolkit, such as GLFW or SDL, of which several
 are already around.

I put my bindings up at http://www.algonet.se/~afb/d/ a few years ago, generated with... you guessed it: http://www.algonet.se/~afb/d/h2d.pl ...
 I would say templated-containers are desperately needed, before
 everyone rolls their own non-compatible versions. But GUI stuff (and
 I include OpenGL) in the core library? That requires unified
 cross-platform GUI toolkits, and I don't really think you will find
 anyone willing to invest a few million man-hours in that can of
 worms. What is wrong with just using wxD or similar, rather than
 polluting the standard lib?

Well put, but it wouldn't be too wrong to have e.g. old OpenGL 1.2 bindings or something simple for GUI like MinWin in the core either ? --anders
Jul 12 2007
prev sibling next sibling parent reply Pragma <ericanderton yahoo.removeme.com> writes:
Mikola Lysenko wrote:
 Personally, I think that it would be a bad idea to jump in and add
language-level support for GPU specific functions.  The technology is just
changing so fast right now that any effort would probably be hopelessly
obsolete within a few months.
 
 That said, I think it would be good to get OpenGL / GLSL bindings into the
standard library.  When it comes to graphics, these are basically standard
interfaces, and official library support would be huge.  They provide all the
basic facilities for handling GPGPU, without the built in expiration date. 
Besides, we could leverage the excellent work that has already been done by
Aldacron et.al.  Off the top of my head, I can think of a several benefits of
this approach:
 
 1. Reduced set up hassle
 
 Right now building derelict is a huge PITA.  I know that Derek Parnell and
Aldacron have worked an incredible amount on simplifying this process, but it
is hardly automatic.  On Linux, I need to check out the latest version of
derelict, download build, compile some set up scripts, add paths to my project,
link in libraries, try compiling, then go back and add that -op switch I
forgot, etc. etc.
 
 Making OpenGL work out of the box saves a huge amount of time and agony. 
Imagine how wonderful life could be if all one had to do to was add:
 
 import opengl.gl;
 
 Which leads into my next point:
 
 2.  Built in OpenGL is more newbie friendly
 
 When it comes to attracting novice programmers, graphics are extremely
important.  Most neophyte coders are interested in making games and getting
things running around on the screen.  From personal experience, I can say that
this is how I learned how to program, and also how many of my friends picked up
the skill.  The importance of graphics in attracting and educating new users
can not be overstated.
 
 One of the reasons Python has been so effective in hooking programmers is that
they have a robust set of graphics bindings which are easily available.  C# is
likewise popular because of its XNA game development framework.  Java has been
used in web games since the 1990s, with decent success.   Even C compilers come
with OpenGL bindings installed by default.  For newbies, graphics are much more
compelling then a terminal.
 
 Which brings me to my final point;
 
 3. OpenGL is standard
 
 And it has been the standard for graphics since the early 90s.  It works on
Mac OS, Linux and even Windows.  Solaris has OpenGL support.  Even video game
consoles have OpenGL bindings these days.  In fact, if you include the last
category, there are probably more hardware units out there that have OpenGL
support than there are systems that support ANSI C-style FILE stream IO.
 
 Due to its popularity, this interface is probably not going to change much in
the coming years.  Granted Khronos group and company are revamping the
specification, but it is doubtful that this will happen at the expense of
backwards compatibility.
 
 Besides, Aldacron has basically worked out most of the details involved in
getting future-proofed OpenGL bindings up and running.  I'm sure it shouldn't
be too hard to work out some scheme for incorporating a stable version of
derelict into the main trunk of either Phobos and/or Tango.  The added
development overhead would be so low in comparison to the huge benefit for the
community.
 
 Of course not every little feature should get library level support, but it
just seems bizarre that something so essential is only available via a third
party add on.  Granted, we also need GUI utilities and template containers, but
I suspect that both of these will come in time.
 
 -Mik

This is a very wise recommendation for D. Building a platform library with everything, including kitchen sink, can be a nightmare to maintain - adding something as rudimentary as GL is nowhere close to that scenario, yet gives developers a much broader base to build upon. If I may ask: what is your take on how GL should be provided as a D library? There are any number of ways to go, ranging from a full-fledged OO wrapper to a faithful port of the C headers and interfaces and everything in between (assuming you're not proposing that we just fold Derelict in with Phobos or Tango). -- - EricAnderton at yahoo
Jul 12 2007
parent Mikola Lysenko <mikolalysenko gmail.com> writes:
Pragma Wrote:
 
 If I may ask: what is your take on how GL should be provided as a D library? 
There are any number of ways to go, 
 ranging from a full-fledged OO wrapper to a faithful port of the C headers and
interfaces and everything in between 
 (assuming you're not proposing that we just fold Derelict in with Phobos or
Tango).
 

I think that the best strategy is to match the C interface as closely as possible. The problem with using higher level D specific features is that OpenGL changes far too often for high level stuff to make much sense. Limiting it to C functions basically ensures that no matter what the Khronos group & co. add, it can always be accessed directly. This is especially true for vendor specific extensions which are often necessary for writing high performance GL code. Likewise, many online examples are written for C-style OpenGL code. Porting them to D is much easier if D matches the functionality exactly. This ties in pretty well with the idea that adding OpenGL support should make D more newbie friendly. Finally, OpenGL itself isn't tied down to any specific windowing library or platform. If you stick to the C stuff, there is virtually no chance that you are going to step on the toes of any windowing kit out there. However, this is also where the idea unravels a bit. While OpenGL by itself is wholly reasonable to support, in order for it to actually do anything you need a host of other windowing and input functions. One good compromise could be adding a GLUT-style windowing kit to D, but this would incur a substantial amount of work. The problem is that all of the frameworks that I know of have at least one or two pathological flaws which make them break D in unpleasant ways. In brief: GLUT - Requires C-style function pointers for various window functions. This typically breaks with D code, and requires a bunch of messy casting. At the very minimal you would need to wrap ~90% of the library methods in a D language thunk. SDL - Hijacks main() with SDL_main(). This causes a lot of current D code to break in unpleasant ways. Also, it has a lot of bloat, such as various 2D sprite drawing things that are pretty much irrelevant for OpenGL applications. GTK - Far too huge. Also requires a substantial runtime library install on windows. Platform specific stuff (Win32, X, etc.) - In general decent usability from D, but completely unportable. Overall, it seems like a bit of a dilemma. Of all the systems I've seen probably the best candidate is GLFW. It is small, supports static linking, has a consistent interface, and is widely portable. The main drawback is that it is good for getting a window open and not much else. It would probably function as a decent stand-in until someone gets a real UI library together for D. Even then, it could still be a nice alternative for users who don't want to deal with a lot of extra set up hassle. -Mik
Jul 12 2007
prev sibling parent reply "Craig Black" <cblack ara.com> writes:
I've heard that recent versions of OpenGL have some GPGPU support, but I 
don't know any details.  Anyone know where I could get this information?

-Craig 
Jul 12 2007
parent reply Mikola Lysenko <mikolalysenko gmail.com> writes:
Craig Black Wrote:

 I've heard that recent versions of OpenGL have some GPGPU support, but I 
 don't know any details.  Anyone know where I could get this information?

GPGPU isn't really something that is supported, more as it is a terrible hack. In theory, all you need are a few basic OpenGL extensions to make it work. The basic idea is that you convert some (or all) of your computations into fragment shader operations, then feed them your data in the form a texture to get your result. Making it all work isn't really pretty, and the tricks involved vary a lot from problem to problem. In general, the basic strategy is to get the GPU to do as much as possible without CPU intervention. For a brief tutorial see: http://www.mathematik.uni-dortmund.de/~goeddeke/gpgpu/tutorial.html More recently, the GPGPU community has been moving toward unified languages with much better support. Right now the cutting edge technology is NVidia's CUDA language. It is essentially a hacked up version of GCC with some support for running functions on the GPU. I think it would be a very poor decision if D were to try incorporating these features at this time, since current development efforts are very closely tied to the hardware itself. As NVidia keeps iterating their GPU technology, I would expect that these languages will change drastically - as well as their underlying interfaces. Here is a link to the CUDA toolkit/compiler: http://developer.nvidia.com/object/cuda.html -Mik
Jul 12 2007
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
With D's insane metaprogramming capabilities, someone probably just needs to
create a library for GPGPU similar to BLADE or something, where it analyzes
what you're trying to do with D code (passed in as a compile-time string) and
transforms it into GPU operations.

Mikola Lysenko Wrote:

 Craig Black Wrote:
 
 I've heard that recent versions of OpenGL have some GPGPU support, but I 
 don't know any details.  Anyone know where I could get this information?

GPGPU isn't really something that is supported, more as it is a terrible hack. In theory, all you need are a few basic OpenGL extensions to make it work. The basic idea is that you convert some (or all) of your computations into fragment shader operations, then feed them your data in the form a texture to get your result. Making it all work isn't really pretty, and the tricks involved vary a lot from problem to problem. In general, the basic strategy is to get the GPU to do as much as possible without CPU intervention. For a brief tutorial see: http://www.mathematik.uni-dortmund.de/~goeddeke/gpgpu/tutorial.html More recently, the GPGPU community has been moving toward unified languages with much better support. Right now the cutting edge technology is NVidia's CUDA language. It is essentially a hacked up version of GCC with some support for running functions on the GPU. I think it would be a very poor decision if D were to try incorporating these features at this time, since current development efforts are very closely tied to the hardware itself. As NVidia keeps iterating their GPU technology, I would expect that these languages will change drastically - as well as their underlying interfaces. Here is a link to the CUDA toolkit/compiler: http://developer.nvidia.com/object/cuda.html -Mik

Jul 12 2007
parent Don Clugston <dac nospam.com.au> writes:
Robert Fraser wrote:
 With D's insane metaprogramming capabilities, someone probably just needs to
create a library for GPGPU similar to BLADE or something, where it analyzes
what you're trying to do with D code (passed in as a compile-time string) and
transforms it into GPU operations.

Indeed. I've had a quick look, and it actually looks straightforward. And a great opportunity to blow the socks off everything else. <g>
 
 Mikola Lysenko Wrote:
 
 Craig Black Wrote:

 I've heard that recent versions of OpenGL have some GPGPU support, but I 
 don't know any details.  Anyone know where I could get this information?

http://www.mathematik.uni-dortmund.de/~goeddeke/gpgpu/tutorial.html More recently, the GPGPU community has been moving toward unified languages with much better support. Right now the cutting edge technology is NVidia's CUDA language. It is essentially a hacked up version of GCC with some support for running functions on the GPU. I think it would be a very poor decision if D were to try incorporating these features at this time, since current development efforts are very closely tied to the hardware itself. As NVidia keeps iterating their GPU technology, I would expect that these languages will change drastically - as well as their underlying interfaces. Here is a link to the CUDA toolkit/compiler: http://developer.nvidia.com/object/cuda.html -Mik


Jul 12 2007