Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
Posted Feb 14, 2013 8:13 UTC (Thu) by mmarq (guest, #2332)In reply to: Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel by brouhaha
Parent article: Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
Uff!... thank god! lol
I want the tremendous *compute power* of the GPGPU ... i want the ability to do "co-designed" on-the-fly binary translation with profiling for that compute power... i want all my graphics ray-traced for illumination, with OpenCL style physics effects ( hey! why not a KDE or Gnome environment with "physics" effects and animations ?... not only games ??)
quite a list no!? ... i think doing all that from userspace would make programing Cell look like superball.. lol
Posted Feb 14, 2013 18:01 UTC (Thu)
by nix (subscriber, #2304)
[Link] (21 responses)
But things like physical memory management and mediation between competing users -- that's what kernels *do*. It's what they do for the realm the CPUs rule over, and it seems perfectly sensible to have them do it for the GPU's realm too (and a heck of a lot more robust than the alternative).
Posted Feb 14, 2013 19:39 UTC (Thu)
by mmarq (guest, #2332)
[Link] (16 responses)
If traces parallels with Android model, yes they might adopt something like Aparapi (translates Java into OpenCL like, with knowledge of target ISAs) and push for a backend compiler or "finalizer" into the kernel.
But this is quite smaller than LLVM and resides below LLVM...quite low level.
Posted Feb 15, 2013 18:15 UTC (Fri)
by nix (subscriber, #2304)
[Link] (15 responses)
Posted Feb 18, 2013 4:21 UTC (Mon)
by mmarq (guest, #2332)
[Link] (14 responses)
I'll try in lay terms (warning: NOT a developer of this)
The HSA standard if that is what we are following, doesn't need kernel inclusions... i'm confident... not even the runtime... only the "finalizer" that touches metal directly could induce the need.
This back-end compiler is very ISA specific, is its job->knowing well the target and optimize for it with runtime info, its a JIT compiler, things that static compilers cannot do(well), even LLVM that sits above;
So most probably will be several different "finalizers" for the many "processores" HSA encompasses, including not only ARM/AMD/Imagination GPUs but also TI DSPs etc.
So it could be a DKMS feature, if Linux supports DKMS properly(?)...
Matter of fact it doesn't even have to be a "finalizer", the HSA runtime can take care of that like the OpenCL runtime or the C++11/AMP runtime does.
For the more performance aware version with a "finalizer", the only features that touch hardware are DMA(direct memory access), VM stuff, TLB stuff, scheduling and IOMMU stuff... things that seem not indicate GPU at all no ?...
And it could be done by improving what is already there... i don't think the patches must be intrusive if it comes to that, since the hardware features listed on the spec are really very small.
Matter of fact the basic spec seems like any other language, with its proper runtime... and i don't see the need for C or C++ libs on the kernel(?)... neither should this, tough its idiom HSAIL, is very low level and compatible with LLVM IL SSA, that is, it takes SSA transforms it to HSAIL then native by a "finalizer", this if you want your program having the same Virtual Memory space, meaning CPU + GPU/DSP/etc will have the same space for better integration overall... then the "finalizer" is the way to go...
OTOH it can also proceed directly from the IL to the target by the runtime, and a program can be build with both targets by their tools, native + HSAIL(finalizer), using exactly the same code, so even if Intel NEVER implements the hardware features, any HSA program could run on any Intel CPU *platform*(so far) **UNCHANGED**...
Only with the "finalizer" stuff, the program can run quicker in perhaps most cases(if properly coded)(less heavy or less specific stuff and suspect no difference at all)...
The idea is not only use the same *virtual memory space*, is use ANY language to program it... and much better than nVidia CUDA IMHO... it goes so far to support, C/C++, AMP, OpenCL, fortran Java(+scripts) Python and more, i think more than the supported natively by LLVM...
The advantage with a "common virtual space" is that any GPU/DSP/etc memory will be managed as system memory not a different pool... also the GPU/DSP/etc could have its context/exception handling and interrupt handling mostly outside of any CPU control (like if it were another CPU), which is better for power management... its a UMA heterogeneous SMP architecture, an obvious very good evolution to the co-processor idea...
intros
The drawback with this is i don't know if its compatible with the current DRM implementation, or if it can be patched to it, since rendering seems only one of the features that encompasses the standard, it could be complementary... or perhaps!... Intel top management, namely its CEO gets one of those Christmas Ghost moments, and Intel joins the HSA... eh!... without need for false promises to the ghost lol... since Intel doesn't need to license anything (i think), it only have to make its hardware features compatible -> then there will be no bickering but a patch flood... lol
Posted Feb 18, 2013 4:28 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (13 responses)
Yeah, it will immediately beat all other architectures, sure.
Posted Feb 18, 2013 5:07 UTC (Mon)
by mmarq (guest, #2332)
[Link] (12 responses)
Sorry but you are babbling nonsense... without ever having toke a pick on anything...
Only Samsung itself is bigger than Intel, and its not only IT stuff, Samsung and LG makes perhaps the majority of the consumer electronics world...
Posted Feb 18, 2013 5:23 UTC (Mon)
by mmarq (guest, #2332)
[Link] (6 responses)
*Sony*, Samsung, LG... IT IS *THE* consumer electronics world...
You better say "i don't want Linux on those things"... hard task to fulfill no doubt... and the new Playstation IV, you also don't want to see it with a Linux OS ??... doubt they will ever license Microsoft, or (M$ would accept)...
Well, PS IV is going to be HSA modeled... is not PowerPC, is x86 AMD, and Sony entered the HSA... the academic guys grow up and made real hardware lol ... and a flush of shills entered the Linux forums, or is that veterans went to sleep... or are pesky politics abounding ... ummm !!?..
Posted Feb 19, 2013 19:25 UTC (Tue)
by khim (subscriber, #9252)
[Link] (5 responses)
Wow! Looks like SONY just can't ever produce nice, easy-to-program console. After Cell fiasco (which is theoretically so much more powerful then XBox's CPU but so hard to program that most PS3 game ports are inferior to XBox360) then decided to use of-the-shelf-hardware but now they want to still screw the developers in some other way? I wish them luck, they'll need it.
Posted Feb 19, 2013 22:50 UTC (Tue)
by mmarq (guest, #2332)
[Link] (4 responses)
Sony should not be about nice and easy to program... it would be nice for a change... but primarily Sonny i think is after "PERFORMANCE"(try to match both the why of HSA)
See!?... the reason is simple, many bickering in hardware/review sites... but its seems CLEAR that if you want performance, PERFORMANCE IS IN THE SOFTWARE... arguing this CPU and that processor is best than this or that, only controversy to entertain morons!... it is best but with what software ???
More!... according to a leak that circulates, the Durango GPGPU that goes for the Xbox720 is very unusual and seems a highly customized design... many still do laugh and foresee the doom of Xbox, but that is what Microsoft choose, perhaps fitting better their tools and their programming paradigms... since its clear PERFORMANCE IS IN THE SOFTWARE, its highly premature to judge anything only by the hardware features alone...
So your argument of "off-the shelf" is simple WRONG by many accounts... and you should applaud because gives the software side much more leverage.
But i understand your point about "off-the shelf", the "traditional" world of graphics and video is just too stupid to begin with... with super bloated Driver an VM JIT layers for the GLs of the GPGPUs -> crazy!, usually those Console guys **program much more to-the-GPGPU-metal** and are able to extract an **order of magnitude (10x) more performance** than in the "PC world"... Microsoft is in the same boat some how, Xbox and Microsoft will be around *compute* and C++AMP allover...
LINUX IS NOT ABOUT "COMPUTE POWER", AND POWERS SEEMS NOT WANTING IT TO BE... that is why client side "mass adoption" concerning (it has to do with graphics/video)... Microsoft will win for Linux in the foreseeable future, and history repeats itself... even when they F### up as they did with Windows 8...
Sounds crazy but its true... and there is where HSA foundation entered... the idea is exactly "facilitate" this, open it to general languages, and that is why it catched so many interest and is a "de-facto" and "de-jure" standard right now.
Posted Feb 20, 2013 17:54 UTC (Wed)
by khim (subscriber, #9252)
[Link] (3 responses)
This one phrase says it all: bollocks. If you ever actually go and compare console versions of games and PC versions of the same you'll see that yes, they achive "10x more performance"... by replacing nice textures with tesselation and other niceties with blurry POS. Hardly an achievement worthy talking about. I think I'll side with viro: this is not a slashdot and since effective discussion with you is impossible I'll just use this nice LWN's feature and silence you in my stream. Have a nice day.
Posted Feb 20, 2013 22:17 UTC (Wed)
by mmarq (guest, #2332)
[Link]
I even can agree with some things you say, but everything must be in its proper context, and those are not fixed, they evolve tremendously...
Its not to hurt feelings, to make controversy... but the idea i trowed about forking the Linux Kernel... as exposed... perhaps are not off base.
And i'm not the right person to answer most things, i'm sure the HSA have ppl around here, they could answer erroneous ideas if they are "allowed"... perhaps in another thread...
Posted Feb 21, 2013 8:11 UTC (Thu)
by elanthis (guest, #6227)
[Link] (1 responses)
There was some AMD buffoon who clearly only knew consoles claiming that D3D12 would likely do away with most of the API since developers wanted to directly target the hardware. This is obviously impossible in a world with multiple GPU vendors, and even things like AMD replacing its machine code format in its own product line.
Also, we don't _want_ to do this direct hardware coding so much as we _have to_ to make sure the games we put out in 2012 looked better than our competitors' games in 2008 despite using the exact same hardware. We have to push micro-optimizations and tricks to improve performance because the hardware is locked in the stone age.
Consoles can be faster than an equivalent PC because we have no real OS and can micro-optimize in ways that PC/phone developers can't. This is not a good thing, for developers or users. Users want diversity and competition, and developers want easy APIs that make development cheap and efficient. Consoles do neither.
Meanwhile, real PCs can massively outperform consoles because for all the bloat, the hardware is massively more powerful, partly because many companies can compete to make the best hardware and users can and do upgrade at will. So mmarq's argument is just silly. Hardware does bring massive performance improvements, and software trickery is about making the most of limited hardware.
Posted Feb 21, 2013 9:18 UTC (Thu)
by khim (subscriber, #9252)
[Link]
Posted Feb 18, 2013 5:51 UTC (Mon)
by dlang (guest, #313)
[Link] (2 responses)
These vendors are examples of where things are not working, not examples that we should be following.
Posted Feb 18, 2013 8:23 UTC (Mon)
by mmarq (guest, #2332)
[Link] (1 responses)
I don't know what is the politics of HSA what they decided... but i think they have serious problems... and drivers is not the only concern...
They must have an *Open OS*... for their *Open Standards* -> they are open, all GPL compatible(Double licensing may be used, but also BSD style is used and not only LLVM)
IBM is not in it(doubt ever will, its not its targets, unless they pass to use GPGPUs and stuff for computation, which also doesn't make much sense for them )...
Apple though based on ARM will not go for it, open their OS, even if they join...
Microsoft the same or worst...
BSD are too lacking for "devices & stuff" and getting obsoleted by Linux
*\\It remains only Linux//*
More than drivers, i think it would be wise to see if they could build ALL of an OS, if not almost all of a Distro, using their very comprehensive compiler toolchain... and which could very well be ***much more ARMv8 64 bit centric than x86***.
GCC is in a paradox crosswords as reported by Pharonix, Intel ICC is too CPU centric and will remain as foreseeable, even if they open source it, and worst doubt they will ever target ARM...
Since they set Most of Industry, including the leaders of the client side of computing, ARM Samsung & CE, to build a top nosh compiler toolchain designed specifically for this... one natural candidate might be Android...
But i can't see if Google is up to it, they may decide to go a little like Apple/M$ and target primely their stuff... its Linux based, its some proprietary to, and they might NOT be to take the BURDEN...
HSA is big, they can do it...
So what only remains is fork the Linux kernel itself... I SEE NOTHING HOSTILE IN THIS... IT WOULD BE EXACTLY LIKE *ANOTHER* DISTRO BUT ONE THAT WOULD GO MUCH DEEPER THAN THE USUAL, WITH THE APPLYING PATCHES NOT APPROVED/WAITING MAINLINE... ALL DISTROS DO IT MORE OR LESS...
In the end LF and Linux can also benefit from it, it will be like another branch, and it already maintains several, so another one maintained elsewhere doesn't hurt... and build with HSA CC, and with its driver interfaces, which could be DKMS++ based and used also by many other distros ... and who knows if not useful in the future, who knows about GCC -> can it evolve ?
I'm afraid with the politics not all is rosy, or if anyone can ask more than the remarkable work that has been done so far by the LF, but when the HSA compiler collection is finished, they must find a real USEFUL solution and they would want to really test it with an OS... they will have no other choice, but to find that solution -> you simple don't waste a lot of time expertize and money building something and then not use it...
Don't know politics, but i see it like an addition... not something bad... distros, for everyone that flanked along this years, 2 more seemed to have popped out in its place, many with many peculiarities, everyone trying to be different... what would be the danger of having another one ??...
It would be not an attempt to take over... matter of fact i think exactly like any other distro, they would link LF attentively and try to participate, only they could go very different in a lot of changes...
The GPL is not really suitable for "exclusivity or my way or the highway kind of approaches", who ever thought of that must be desperate or in deep delusion...
In the end i don't know the decisions... but also i don't see many other options...
Posted Feb 18, 2013 9:12 UTC (Mon)
by mmarq (guest, #2332)
[Link]
I mean it is used, and could be used extensively... but doubt it will ever produce any political results for any particular agenda or impediments to others... besides exactly a cave-in choice from the producer... and doubt any "forcing" effect in any sizable receiver
That could have worked more or less for the type of distros he had so far... and even so not all... and none in strict patch software feature choice..
Linux as been protected by the inherent complexity from fork pressure and be able to dictate...
Android breached that somehow... in the future it can be much worst... and its not only about HSA...
So i find this comments about "my way" kind of vision and we should pursue this and not that very amusing... probably not conscious kernel devs, if one at all... and the case is you should pursue what you think best, but abstain from such comments.. lol...
Posted Feb 19, 2013 19:25 UTC (Tue)
by khim (subscriber, #9252)
[Link] (1 responses)
Nope. These are companies which cough up few millions here and there to make sure they'll be in the loop if this idea will actually reach some usable stage. Does not mean anything beyond that at this point. Remember the last "next big revolution" (called EPIC if you forgot)? It also had an impressive names: Intel, HP, IBM (which wanted to use the opportunity to unify UNIX), etc. They had really awesome slides! And really cool story. I'd say EPIC story. In the end we've got an epic fail, nothing more. I'm not saying they'll fail but the fact remains: number of supporters and sizes of such supporters don't automatically equal success.
Posted Feb 19, 2013 23:41 UTC (Tue)
by mmarq (guest, #2332)
[Link]
HSA is NOT about a CPU u-arch... at best its about a macro-arch concept, one which is highly flexible... but most of all is about a "PROGRAMMING PARADIGM"...
So according to the names involved, because *they use it*... HSA fits nicely with ARM, x86, MIPS and PowerPC(thought Sony changed, i think its used on some other stuff by some) on the CPU side... TI, ARM, MIPS etc DSPs... all the analogue stuff of ST-Ericsson and MIPS and ARM etc... and its open to many more!...
So catching a few millions here and there, all those guys make many times the size of Intel as example (5x perhaps !?)... Only Samsung itself is bigger than Intel... no matter how much many dogmatic sectarian POV wants to twisted it, it is truth...
Also no matter how hard it takes to many... can be debatable, but highly dependent on how and what you count... from Smarth/Superphones to desktop, by *unit accounts*, the CPU u-arch leader of the client side of computing is ARM not x86... an nothing will prevent with ARMv8 64bit, the spill in force into the traditional Mobile (laptop) side of computing and even some desktop( in this earlier steps)... not even if Intel goes thermonuclear (its too late now).
I think Google saw the light... "renderscript" smells HSA allover some how, and staying more ARM centered and not MIPS or x86... Android will be the only real fight to Microsoft in the client side... though Apple will remain very big, as big as Intel, i think they are "too closed" to ever be the clear dominant force on the client side.
Posted Feb 14, 2013 20:11 UTC (Thu)
by mmarq (guest, #2332)
[Link] (3 responses)
I don't know why you gentlemn fear or oppose some of this kernel inclusions. It could be modular a compile option, and import little additional maintenance burden... or the opposite, if with those it imports also additional savyy developers.
Posted Feb 15, 2013 18:18 UTC (Fri)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Feb 18, 2013 4:57 UTC (Mon)
by mmarq (guest, #2332)
[Link] (1 responses)
ummm... stange agendas !... DKMS is exactly a good idea for the overburden complains. Don't know why Kernel devs must maintain every thing about drivers... lots of bickering yet it already imports firmware blobs, when there could be a proper interface (discussed/DESIGNED case to case of family, and parts of DKMS changed accordingly)...
Then the more generic stuff goes kernel maintenance... APIs don't change that often(matter of fact quite unoften for many tastes)...come on you know its truth!... and the burden to support every single variant of a hardware family goes to the vendors... like half half...
Free drivers could co-exist with proprietary,*** which they already do***, so nothing new and nobody got hurt, and if properly designed, more things could be open and free drivers use a lot of the same stuff of the proprietary ones without the need to be a mess of half finished things and proprietary drivers that break at every 2 versions...
And if security bitching is a concern, why not direct the program caging and sandboxing to the DKMS side and really support it, instead of shoving it to the unsuspected user, that by no dreams will ever be using NSA grade...
About KMS it makes good sense in userspace... the reason is that consoles will also want to use the possibilities, kernel interfaces directly, so its sensible...
The other arguing, maintenance, stuff... issues... preferences... tastes...particular visions.... semantics for pointless bickering.
10 years and little change to many things.. oh! well, progress is not painless... action counter-reaction applies here to... (damn politics!)
Posted Feb 25, 2013 17:02 UTC (Mon)
by nix (subscriber, #2304)
[Link]
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
Don't follow, who said about puttin LLVM into the kernel ?
You did. The 'tremendous compute power of the GPGPU' is implemented by compiling things targetted to the GPU, via LLVM (at least that's the lion's share of it). Putting that in the kernel means putting LLVM in the kernel.
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
http://www.slideshare.net/hsafoundation/hsa10-whitepaper
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
Well, PS IV is going to be HSA modeled... is not PowerPC, is x86 AMD, and Sony entered the HSA...
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
usually those Console guys **program much more to-the-GPGPU-metal** and are able to extract an **order of magnitude (10x) more performance** than in the "PC world"
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
The only games which "make way more use of the hardware in consoles" are exclusives like Uncharted where you really can throw away all these HSA discussions and code to bare metal. Most cross-platform games (and very few games are exclusives nowadays) are better in XBox360 because it's hardware is closer to PC and usually you don't need 10x more powerful PC to beat the console game in quality (2x is more then enough) which implies that these "micro-optimizations and tricks" are not all that popular. They are used in some "computationally heavy" places (because otherwise game will just not work on console) but most of the time it's just plain simple reduction in quality (number and size of textures, etc) till you have the required FPS. And of course there are no HSA or "bare metal" access: it's OpenGL or Direct3D on consoles, too.
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
Samsung, ARM, TI, Sony, AMD, Imagination, LG, STMicro, ST Ericsson etc etc etc... are academic guys without real hardware ?
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
The other arguing, maintenance, stuff... issues... preferences... tastes...particular visions.... semantics for pointless bickering.
So... not having to implement everything twice is 'semantics for pointless bickering'? Ooh-kay.