If you aren't building your data-oriented, sparse voxel ray-casting + deferred rendering + real-time radiosity FUTURE ENGINE® for Tomorrow's Games™ using OpenCL™ 2.0, you're doing it wrong.
>>1
Well, that's great an all, for specific applications. General PC OS programming, no.
Name:
Anonymous2013-07-23 23:42
AMD announces that they're open sourcing their entire OpenCL 2.0 stack for HSA Fusion devices (the same platform used by both the PS4, XBox One, Steam Box, and probably many lightweight desktop systems) under the very liberal University of Illinois/NCSA open source license, with support for FreeBSD and Linux out of the box.
Name:
Anonymous2013-07-23 23:48
>>3
Wrong. OpenCL is for CPU programming too. Imagine writing your game update code using the same kernel shading language that you use for graphics, using float4 SIMD types and branchless transformations; you no longer have to acclimate when switching between CPU or GPU programming, and it'll automatically scale across all of your cores via grid-partitioning.
Imagine being able to DMA the results of such a transformation directly to your GPU where it can be used as input for rendering graphics.
Imagine being able to schedule your asynchronous file-system streaming and caching code with the same task scheduler underlying OpenCL, and have it all work seamlessly.
Imagine not having to mess around with pthreads or winthreads so much.
Imagine this all being portable, and available on desktop computers, mobile phones, and game consoles.
>>4
Fine, because Pandora, GP2X, Uzebox, Fuzebox, Dingoo A320, OUYA™, GCW Zero™, etc. are not the market prospects.
OpenCL was initially developed by Apple Inc., which holds trademark rights, and refined into an initial proposal in collaboration with technical teams at AMD, IBM, Qualcomm, Intel, and Nvidia. Apple submitted this initial proposal to the Khronos Group. On 16 June 2008, the Khronos Compute Working Group was formed[3] with representatives from CPU, GPU, embedded-processor, and software companies. This group worked for five months to finish the technical details of the specification for OpenCL 1.0 by 18 November 2008.[4] This technical specification was reviewed by the Khronos members and approved for public release on 8 December 2008.[5]
Name:
Anonymous2013-07-24 0:11
>Pandora, et. al.
>ARM Cortex A8/A9/A15 & Imagination Tech PowerVR SGX
>both already have OpenCL 1.2 conformance drivers, will soon have 2.0
>OUYA
>Not a market failure
>Nshitia Tegra
Name:
Anonymous2013-07-24 0:14
>>6
Google is including OpenCL in the next Android release.
>>5 Imagine writing your game update code using the same kernel[...]
Specific application Imagine being able to DMA the results [...] directly to your GPU
When required. Most environment have multiple processes, and multiple users. Most Desktop OSes are like this, and have their own CPU scheduler you cannot tailor on the fly, just for that application. Imagine being able to schedule your asynchronous file-system streaming and caching code
Nice, we use filesystems for that, and compile at the kernel level. Know ZFS? Imagine not having to mess around with pthreads or winthreads
Know pthreads? Imagine this all being portable
Know POSIX?
It's happening!
I know, it is. And it has been great for many customised applications (server farms, research, RTOS, Beowulf cluster, customized applications, embeded applications, etc.) But it is not the right library for everything.
Name:
Anonymous2013-07-24 0:19
But it is not the right library for everything.
Correct. LISP is right for everything. Why use a library when you can use a powerful language like LISP?
>>7
making fun of >>4 non-citated source. Also, there are some other Archs there, MIPS included.
Name:
Anonymous2013-07-24 1:58
OpenCL will be useful in a few decades.Maybe.
1.theres a lot of non-OpenCL hardware that doesn't gain any benefit from it.
2.The syntax is superfluous,arcane and WindowsAPI-like.
3.The CPU/GPU merger heralded by AMDFusion should produce something more manageable.
Name:
Anonymous2013-07-24 2:07
>>10
There's no such language as LISP.
No language in the LISP family is powerful. They don't even have a real syntax, none of them.
Name:
Anonymous2013-07-24 2:09
>>13
Syntax is a commitment to a specific structure, which is already a loss of power.
Name:
Anonymous2013-07-24 2:41
>>14
Syntax is an imporvement in expressive power and readability, which is already a gain in power.
Even the Nikiketa, though he's a lisp idiot, chooses syntax over no-syntax.
Name:
Anonymous2013-07-24 2:46
>>15
While it provides a boost in readability and succinctness, syntax does not effect expressive power. Syntax by itself does not limit expressive power, but the inability to escape the syntax is a loss of power.
Name:
Anonymous2013-07-24 2:48
Do you really think that OpenCL will enable access to future engines ? LE EGIN LEL. There is no such thing, noone wants to pay unlimited dollars to a GPU which will support the newest openCL. No.
Name:
Anonymous2013-07-24 3:14
>>16
Whenever you need to escape the Syntax, you just start writing in a different language. There is NO need to waddle in the parenthetic mire of lisp, ever. And practice confirms this: LISP is dead. Well, there is one little Clojure (the most popular LISP), but it is only so popular because it stands on the shoulders of a giant, the JVM — not because it's a LSIP.
Name:
Anonymous2013-07-24 3:28
>>18
No language allows you to define your own language and use it as first class constructs within the original language as well as LISP. You can use multiple languages, and if you work hard enough, you can create your own language-like abstractions, compile your language to the original lang and link everything together, but it's a lot of work. If it's a lot of work, you wont be able to do it in your time constraint. And if you wont be able to do it, you'll use some crappy hack instead. No other language can do what lisp does as well, and they pay for it. But lisp is shit for many unrelated reasons, so you couldn't use it in these environments anyways.
Name:
Anonymous2013-07-24 3:34
>>19
But no one need to define a full-scale language! There's already a ton of different languages out there and you can always find one that fits a particular purpose well.
Name:
Anonymous2013-07-24 3:48
>>20
If you go far enough into your own niche, you'll find a need, however trivial, that isn't addressed by anything else out there. The kinds of things that I'm talking about here are tasks that you might try to use the c preprocessor for, but then give up because it simply can't be done. It's just pushing a shitty tool past its limit. Lisp has the power to go wherever you may find yourself, and you can hack together what you need about one hour after you find out you need it.
I feel like I'm writing an advertisement for a power drill, ducttape, or condoms. Gosh...
Name:
Anonymous2013-07-24 4:16
If you go far enough into your own niche, you'll find a need, however trivial, that isn't addressed by anything else out there. The kinds of things that I'm talking about here are tasks that you might try to use the c preprocessor for, but then give up because it simply can't be done. It's just pushing a shitty tool past its limit. The Haskell category package has the power to go wherever you may find yourself, and you can hack together what you need about one hour after you find out you need it.
Name:
Anonymous2013-07-24 4:24
>>24
Maybe, maybe lisp and haskell can have a happy marriage.
Name:
Anonymous2013-07-24 4:34
If you go far enough into your own niche, you'll find a need, however trivial, that isn't addressed by anything else out there. The kinds of things that I'm talking about here are tasks that you might try to use the c preprocessor for, but then give up because it simply can't be done. It's just pushing a shitty tool past its limit. The C++ ecosystem has the power to go wherever you may find yourself, and you can hack together what you need about one hourdaymonthyear after you find out you need it.