The ground-up redesign of OpenGL, now called Vulkan, has been announced at GDC:

http://www.phoronix.com/scan.php?page=article&item=khronos-vulcan-spirv

Both graphics shaders and the latest verson of OpenCL, which enables computation on the GPU, will target a new IR called SPIR-V:

http://www.anandtech.com/show/9039/khronos-announces-opencl-21-c-comes-to-opencl

Rather than being forced to use C-like languages like GLSL or OpenCL in the past, this new IR will allow writing graphics shaders and OpenCL code using any language, including a subset of C++14 stripped of exceptions, function pointers, and virtual functions.

This would be a good opportunity for D, if ldc or gdc could be made to target SPIR-V.  Ldc would seem to have a leg up, since SPIR was originally based on LLVM IR before diverging with SPIR-V.

On 6 Mar 2015 23:30, "Joakim via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:
>
> The ground-up redesign of OpenGL, now called Vulkan, has been announced
at GDC:
>
> http://www.phoronix.com/scan.php?page=article&item=khronos-vulcan-spirv
>
> Both graphics shaders and the latest verson of OpenCL, which enables
computation on the GPU, will target a new IR called SPIR-V:
>
>
http://www.anandtech.com/show/9039/khronos-announces-opencl-21-c-comes-to-opencl
>
> Rather than being forced to use C-like languages like GLSL or OpenCL in
the past, this new IR will allow writing graphics shaders and OpenCL code using any language, including a subset of C++14 stripped of exceptions, function pointers, and virtual functions.
>
> This would be a good opportunity for D, if ldc or gdc could be made to
target SPIR-V.  Ldc would seem to have a leg up, since SPIR was originally based on LLVM IR before diverging with SPIR-V.

Unlike LDC, GDC doesn't need to be *made* to target anything.  It's IR is high level enough that you don't need to think (nor care) about your backend target.

GCC itself will need a backend to support it though.  ;)

Iain

On Saturday, 7 March 2015 at 02:18:22 UTC, Iain Buclaw wrote:
> Unlike LDC, GDC doesn't need to be *made* to target anything.  It's IR is
> high level enough that you don't need to think (nor care) about your
> backend target.
>
> GCC itself will need a backend to support it though.  ;)
>
> Iain

Why is that unlike LDC ? LLVM IR is fairly high level (for a compiler IR), is there some specific blocker you are aware of ?

On 7 Mar 2015 04:00, "deadalnix via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On Saturday, 7 March 2015 at 02:18:22 UTC, Iain Buclaw wrote:
>>
>> Unlike LDC, GDC doesn't need to be *made* to target anything.  It's IR is high level enough that you don't need to think (nor care) about your backend target.
>>
>> GCC itself will need a backend to support it though.  ;)
>>
>> Iain
>
>
> Why is that unlike LDC ? LLVM IR is fairly high level (for a compiler
IR), is there some specific blocker you are aware of ?

The necessity of the changes in PR 768 - infact just the fact that LDC needs them raises eyebrows.  :)

Iain

On Sat, 2015-03-07 at 02:18 +0000, Iain Buclaw via Digitalmars-d wrote: […]
> 
> Unlike LDC, GDC doesn't need to be *made* to target anything.  It's IR is high level enough that you don't need to think (nor care) about your backend target.
> 
> GCC itself will need a backend to support it though.  ;)

All Apple's effort will go into Clang, and I suspect they are one of the driving forces behind Vulkan as they were the initiators and driving force behind OpenCL. Thus LDC should be able to get all the work about as "for free" as it gets. The question is whether NVIDIA and Intel will put effort into GCC. If they do then GDC get this about as "for free" as it gets. No-one other than the D community will do this for DMD.

It is not clear how quickly Vulkan compliant hardware will appear, a lot faster than the compilers most likely, but they will get hamstrung with OpenGL and OpenCL compliance – which may end up very annoying, albeit necessary.

Also, of course, there is the huge problem of moving the AAA games world over to all this.

So I suspect we have a few weeks of time (*) to mull over this before it is all in everyone face. But I can see this being big because it is a new thing that games and hardware manufacturers can use for marketing. There is nothing so useful to marketing as something that is genuinely new (**).


(*) well tens of weeks probably.

(**) OK so Vulkan is only new-ish, but the marketers won't care.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Saturday, 7 March 2015 at 03:57:15 UTC, deadalnix wrote:
> On Saturday, 7 March 2015 at 02:18:22 UTC, Iain Buclaw wrote:
>> Unlike LDC, GDC doesn't need to be *made* to target anything.  It's IR is
>> high level enough that you don't need to think (nor care) about your
>> backend target.
>>
>> GCC itself will need a backend to support it though.  ;)
>>
>> Iain
>
> Why is that unlike LDC ? LLVM IR is fairly high level (for a compiler IR), is there some specific blocker you are aware of ?

Bitcode has target-depedent opcodes.

http://llvm.org/devmtg/2011-09-16/EuroLLVM2011-MoreTargetIndependentLLVMBitcode.pdf

"Russel Winder via Digitalmars-d"  wrote in message news:mailman.7407.1425714258.9932.digitalmars-d@puremagic.com...

> No-one other than the D community will do this for DMD.

No-one anywhere will do this for DMD. 

On Sat, 2015-03-07 at 19:16 +1100, Daniel Murphy via Digitalmars-d wrote:
> "Russel Winder via Digitalmars-d"  wrote in message news:mailman.7407.1425714258.9932.digitalmars-d@puremagic.com...
> 
> > No-one other than the D community will do this for DMD.
> 
> No-one anywhere will do this for DMD.

Which would mean that anyone interested in CPU/GPU computing will have to eschew DMD in favour of LDC and GDC.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Saturday, 7 March 2015 at 07:44:18 UTC, Russel Winder wrote:
> It is not clear how quickly Vulkan compliant hardware will appear, a lot

It already exits. Even PowerVR has an (experimental) implementation already...

> Also, of course, there is the huge problem of moving the AAA games world
> over to all this.

Not really, since it is a lot like Mantle...

Vulkan isn't particularly innovative, it is a trip back in time where you have to target the hardware and not the API. Manufacturers like it because there is no point in having high powered GPUs if the applications are  CPU bound and Vulkan get's around that.

But not having an abstraction over the hardware means that devs will suffer, do manual memory management on the GPU, write their own mipmap format routines etc. And you bet the vendors will add all kinds of extensions to it to stay competitive and we will end up with a mess.

On Saturday, 7 March 2015 at 08:41:26 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 7 March 2015 at 07:44:18 UTC, Russel Winder wrote:
>> It is not clear how quickly Vulkan compliant hardware will appear, a lot
>
> It already exits. Even PowerVR has an (experimental) implementation already...
>
>> Also, of course, there is the huge problem of moving the AAA games world
>> over to all this.
>
> Not really, since it is a lot like Mantle...
>
> Vulkan isn't particularly innovative, it is a trip back in time where you have to target the hardware and not the API. Manufacturers like it because there is no point in having high powered GPUs if the applications are  CPU bound and Vulkan get's around that.
>
> But not having an abstraction over the hardware means that devs will suffer, do manual memory management on the GPU, write their own mipmap format routines etc. And you bet the vendors will add all kinds of extensions to it to stay competitive and we will end up with a mess.

I saw a comment in a random forum entry that I cannot recall, that stated an Hello World (triangle) is around 800 lines of C code.


Of course, this doesn't matter when using engines, which every sane developer should do anyway.

Any applications coded straight to graphics APIs ends up being a use case specific mini engine.

--
Paulo