If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

The chances getting GPGPU working on FreeBSD via OpenCL are much better with an open source driver than with nVidias BLOB. nVidia is still not willing to support FreeBSD for this very important GPU usage profile even for the scientific area, where FreeBSD doesn't play any real serious role anymore. FreeBSD is now moving forward with LLVM, LLVM now has the nVidia PTX backend they use for their device target binary code generation for CUDA/OpenCL utilizing LLVM, but it is still not applicable on FreeBSD for the usage with the nVidia BLOB or any library, that provides OpenCL (like FreeOCL or POCL). People underestimate how important this usage of GPGPUs become over the past 24 months and it is like an ultimate sentence, whether the operating system will have a future on the open market/the community or getting dumped into a niche product. Niche products do not get much attention and therefore they will vanish over time.

The long-awaited Intel KMS support for FreeBSD is quite exciting though it's a constant challenge of back-porting changes from the Linux kernel. There's also no official Radeon or Nouveau driver KMS/DRM drivers in FreeBSD.

Well, would this fu...ng X11 foundation do its job right - providing a platform independend graphical users interface as they did in the great time of the UNIXes - their wouldn't be this backporting issue. The OSF blames the *BSD to being behind, the *BSDs blame the OSF for being Linux-nailed. It would be of great interest to figure out what's right and where the truth lies. Indicating that, for instance, the *BSDs are behind is KMS: it is said, that this technique is important to get rid of a root-driven Xorg server, and this should be of great concern even for the OpenBSD people. But there is not much efford to create a platform independend solution. So, at least OpenBSD is behind?

On the other hand, people developing on the drivers are obviously Linux-only and a kind of narrow minded when it comes to more broader views and independend solutions. It seems to be a bit as they are only capable of engineering. Well, that is bad, since engineering makes things, that already exist, better, but it makes us never getting beyond it to gain access to new territories - it is like jet engines and rocket engines. All what's done today is clearly engineering.
The great time, when development was mor open and broad-minded is definitely over and an echo of the past. Today it seems everything is Linux-related in a very clumsy way.

Well, would this fu...ng X11 foundation do its job right - providing a platform independend graphical users interface as they did in the great time of the UNIXes - their wouldn't be this backporting issue. The OSF blames the *BSD to being behind, the *BSDs blame the OSF for being Linux-nailed. It would be of great interest to figure out what's right and where the truth lies. Indicating that, for instance, the *BSDs are behind is KMS: it is said, that this technique is important to get rid of a root-driven Xorg server, and this should be of great concern even for the OpenBSD people. But there is not much efford to create a platform independend solution. So, at least OpenBSD is behind?

On the other hand, people developing on the drivers are obviously Linux-only and a kind of narrow minded when it comes to more broader views and independend solutions. It seems to be a bit as they are only capable of engineering. Well, that is bad, since engineering makes things, that already exist, better, but it makes us never getting beyond it to gain access to new territories - it is like jet engines and rocket engines. All what's done today is clearly engineering.
The great time, when development was mor open and broad-minded is definitely over and an echo of the past. Today it seems everything is Linux-related in a very clumsy way.

OSS video driver's performance is already fairly limited, id rather not drag it down further by having to abstract away the OS dependent portions of it into some OS-agnostic layer. If being Linux-driven or using Linux-specific features means better performance for Linux then I say go ahead and use those features. Yes, KMS should be a bigger deal to the *BSD's (especially OpenBSD) but apparently to them its not worth the effort-- theyre loss.

AFAIK the open source drivers are already quite portable, with most of the OS dependencies (memory management & process control) limited to a couple of areas in the kernel driver. I say "most" because IIRC locking operations are scattered more broadly and I don't know how portable they are.

IMO the bigger issue is that the graphics stack has become a lot more sophisticated over the last few years (hence larger & more complex), while the manpower available for *BSD graphics driver work seems to have gone down if anything, so the big slug of kernel driver enhancements (TTM, KMS) is going to take a while to digest on the BSD side.

Once the KMS/TTM transition has happened it seems like the ongoing work should be more manageable, and no OSes will have to be harmed.

So freeBSD (BDSM) has crapped out more shit to be closed by their pimps M$ and Apple. Whats more is that it's most likely just a relabel to some of their crap to make it look new to scam people.

I looked at the so called "new" features they claim, even if they are true, there is nothing to celebrate about with these features as they were implemented by Linux years before and are now out dated. Dumb retards, Why don't they switch to Linux rather then waste their lives porting these out date things to BDSM. OH WAIT... Their shit and they want to be pimped by M$ and apple and kill linux, Oh well.

Don't be tricked by what they announce on freebsd.org, as it is often not true. I just had a look at the mailing list and apparently, they simply re-label a copy of freebsd 9.0 into freebsd 9.1 as the actual 9.1 source and binaries were deleted by the hackers when they penetrated the system on 11th November.

Come on, FunkSTAR, did you know that FreeBSD is 100% written in Qt? I've also heard that also linux 3.9 will have KDE bundled inside! Don't miss this moronic flame war, these new guys are obscurating you!

Seriously, BSD Sucks and Dies and BSD BullShitDistro (i mean the person behind both), this is the worst trolling ever, this forum is decaying... garegin is the only good troll last.

Divide and Conquer, and just like the flimsy house o' cards ya'll are, you haven't LEARNED anything yet, except for allowing yourselves to be "divided, AND Conquered", and for the last 20 years at that, STILL !!!
It really is NO WONDER anymore, that "western civilization"/capitalism, really hasn't won any wars since WW2 ! -'dats a faq Jack.
The 12th man is LMAO at you both, Linux, and FreeBSD.

Ya'll wonder why ALL the hardware manufacturers' are still un-decided about "openly" supporting "fully" Linux, and/or FreeBSD. ?
Well, just look at this crayon cartoon example from Mr. pea-brain here, not to mention all the other utterly braindead-troll comments here, except for the only intelligent one,-(YES, and thankyou @Eisnefaust), and you'll quickly maybe understand WHY !?

It's about FreeBSD, "and" Linux, working together, and Unix/NetOS's as these, that are thankfully free and open, as these, should be joined-at-the-hip politically-wise, against the proprietary/non-Open/ OS's such as M$, ...
"Rail" at ALL the hardware makers for BETTER, and OPEN Driver support, instead of "RAILING" at each other, and for no reason, but to entertain loser's, and trolls everywhere. ???!!!, wow, I mean wtf? -LoL.

OS, and "ALL" Drivers should be "Free", AND open-sourced. If for nuthin' else, then understand that YOU ALREADY BOUGHT THE HARDWARE, YOU OWN IT NOW !?

(Free)Applications is simply a bonus, but if the Application is good, then pay for it, if the creator wants, or don't use it, find and support your fav free-app.
Hardware, unambiguously, is NOT an option!, and we'll always have to pay for it.