Tweet
Oh and if we are dreaming : resolving the delta between mainline and Android
-
-
Realtime linux patchset ... what would i do without thee?Comment
-
Since more NVMe M.2 drives are underway:
I was wondering whether
made it into 4.9-rc1. And indeed 2/3 of the required patches landed:
while they still sort out
which is this one
Comment
-
Right, where's the LTO support? Doesn't LLVM now support a very lightweight LTO?Comment
-
I was hoping for inclusion of Turbo Boost Max 3.0 so I could the the max out of my Broadwell-E CPU.
CPU MHz: 3600.0000
CPU max MHz: 4000.0000
There is some boost potential there. I just have to hold out for Linux 3.10Comment
-
No possibility to edit. I had some typos in my previous post.
the the max => get the max
3.10 => 4.10Comment
-
DAL merging us getting too slow! I would love to c see an official statement by all the involved programmers.Originally posted by Mickabouille View Post
Are there facts that prove that kernel developers agree unhappy about DAL is an abstraction? If yes, Is possible to make it more direct then? It's a shame abstraction layers are polluting hardware drivers these days.
I hope this gets merged vsoon, as AMD hardware is starting to look interesting, but too many features are still missing. To see AMD hardware interesting, there's need that Zen gets really quite competitive with Intel offerings and only surpassing it in all ways would make AMD relevant again like in the old days. An optimized OpenGL 4.5+ with all extensions and Vulkan certified is a must, Open Source VR is very relevant too. I'm not sure about full OpenCL support, but that CUDA to AMD translator seems a joke
This addition is taking too long, it's really worrying.
Vulkan code had the same luck, but it seems RADV is making v things better. Will it v be competitive against other implementations for other GPUs including NVIDIA and the shameful AMDGPU-PRO?
About AMDGPU-PRO: Kill it with fire, please! AMD has been doing more than enough ridicule with their proprietary drivers and NVIDIA is a shame, but their stubbornness and "optimizations" still make it the only relevant graphics hardware Linux v and certain BSD systems. AMD should stop this crap and make AMD lawyers need to provide a lot more efficacy in their a legal work instead slowing down EVERYTHING! As a "necessary evil", they ought to have a lot faster cooperation and efficiency v to not provide hindrances to the technical part of the company.
Maybe my next desktop will be AMD, I really hope so. I'll only consider only if but only if all AMD hardware have tier1/first class support compared to Microsoft Windows at least and become really competitive with Nvidia and Intel in all means.
If this doesn't gets solved: It will show AMD can't become a serious company and will have the same fate of VIA!
We have enough with with Intel monopoly disguised as duopoly with AMD. You can't find AMD hardware at computer shops and no relevancy at "gaming" laptops too.
People see too much optimism with AMD, I see they don't provide enough resources and their bureaucracy is killing everything. I'll just wait to see. I would love to see AMD finally improve this situation and can make AMD hardware the best option in Linux and BSD by being as lot more community friendly too.
To AMD: I have no dreams, no more. Please provide real results, no more promises.Comment
-
Just look at all the comments devs had when the DAL code was originally published.Originally posted by timofonic View Post
They all say the same thing, basically - why'd you create a new abstraction layer for X, Y, and Z in your driver when the linux kernel already has places where this stuff should go? And if it's not good enough, then fix that rather than putting something in just your own driver.
That's what they're doing now, is taking everything out of DAL and figuring out where it actually belongs in the kernel.
Comment
Comment