This is an awesome news, do you know if Ubuntu finally decided to enable vaapi/vdpau for open source gallium drivers?
Ubuntu Is Deprecating fglrx (Catalyst) In 16.04 LTS
Collapse
X
-
Originally posted by twriter View PostFor those who don't know, I manage AMD's open source graphics team. We (AMD) are focusing our Linux graphics driver development on the amdgpu based open source and upcoming hybrid stacks; consequently, we are not supporting fglrx on Ubuntu 16.04 LTS. Users who require Pro-graphics or Workstation class features and performance can continue to use fglrx on Ubuntu 14.04 until the hybrid stack is available later this year.
Open source performance is (for me) good enough for games that work with it, but the problem is that many of them don't. On numerous occasions I have read that GCN 1.0/1.1 won't be supported by AMDGPU. Does this mean that I should buy a new card if I want to continue to play games (although the current card and drivers that I use are more than capable)? This looks to me like a middle finger to some of your customers, but I still hope I'm wrong...
Comment
-
-
Originally posted by debianxfce View Post
If you have been using rolling release distro like debian testing, there is nothing suicidal with software changes. Amd crimson works with Arch linux patches with kernel 4.5 and you do not have to update xorg to 1.18. In debian it is easy to downgrade xorg, if you do a fresh debian testing install.
ทาง เข้า pg slot 888 เปิดประสบการณ์การเล่นสล็อตออนไลน์ที่เหนือระดับกับ pg slot 888 ด้วยเกมคุณภาพและโบนัสมากมาย เข้าเล่นง่ายผ่านทางเข้าที่ใช้งานได้อย่างปลอดภัย รับรองความสนุกไม่มีเบื่อ พร้อมให้คุณสัมผัสการเดิมพันที่น่าตื่นเต้น
In debian they have not tested fglrx packages, so they are crap. Also with many packages it is more complex to uninstall the driver than using aticonfig --uninstall. Use the .run file from amd and nvidia site when installing, then you have full control to the source code.
I do but only issue is Arch so far don't play happy with my 4790K Haswell driving it to full turbo mode with no scaling due to Arch kernel 300Hz config. Will try Siduction instead to replace Arch.
Comment
-
-
Originally posted by jf33 View PostI think they haven't implemented it, since they already have geometry shaders in core OpenGL 3.2, which offers the same functionality at least. So why don't you just use core geometry shaders?
Now if we are switching from fglrx to mesa, it won't work for much more people, so maybe we should try to find better solution in STK.
Comment
-
-
Originally posted by asdfblah View PostSo, this is official...? fglrx has been deprecated by AMD? WTF? What about older cards and OpenGL 4.5 / OpenCL (in R600), ...?
So don't worry, as AMD devs are focusing on Mesa, there's really no need in FGLRX anymore, it's not even competitive.
Comment
-
-
Originally posted by darkbasic View PostThis is an awesome news, do you know if Ubuntu finally decided to enable vaapi/vdpau for open source gallium drivers?
Comment
-
-
Originally posted by debianxfce View Post
It is just a simple config opton in make xconfig. I use kernels from kernel.org and I tune them way I like. I have overclocked this wait timer too from 250Hz to 300Hz and everthing works fine with Amd A8-7600. I have set cpu core freq scaling to fixed perfromance in the linux configuration, A8-7600 overclocks from 3.1Ghz to 3.8Ghz under load automatically.
Comment
-
-
Originally posted by directhex View Post
The Mesa DRI modules are linked against libstdc++ (see `ldd ldd /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so`)
libstdc++ has a weak ABI represented outside its soname - apps linked against libstdc++ X will not work with libstdc++ X-1 even though both are libstdc++.so.6
Games on Steam run with the "Steam Runtime" shunted into the linker path via LD_LIBRARY_PATH. "Steam Runtime" is a collection of libraries of guaranteed minimum versions - so a game developer can compile against the Steam Runtime, and their game should work on any distribution regardless of the library versions in that distribution.
Steam Runtime contains libstdc++ version GLIBCXX_3.4.19 (GCC 4.8.3)
If your distro mesa uses dynamic linking (all but SteamOS do), and was compiled with GCC 4.9.0 or higher, the Steam Runtime loading triggers an ABI mismatch and will cause DRI to fail to load, and 3D acceleration to fail.
The normal workaround is for users to delete libstdc++ (and libgcc) from their Steam Runtime folder, on Mesa systems.
Here's what the exec line looks like on my Ubuntu 16.04 machine (the libasound part deals with an issue that kept 99% of all games from launching properly. Seems to be fixed with the latest update though):
Exec=env LD_PRELOAD='/usr/$LIB/libstdc++.so.6 /usr/$LIB/libasound.so.2' DISPLAY=:0 steam
Comment
-
-
Originally posted by debianxfce View Post
They are slow and full of unneeded network server stuff. Even former red hat poetterising linux guy recommends custom kernels.
"Don't use debug kernels. Debug kernels are slow. Fedora exclusively uses debug kernels during the development phase of each release"
Comment
-
-
This will bring AMD even lower on Linux market share...
From my recent experiences the open source driver is far to be optimal in performance and features.
Don't get me wrong it is still very good for desktop and most gamers, but for big gamers the ROI is bad.
Now I hope AMD will pump up their OSS team and come back in the race, NVidia is now the only rational choice and I do not like the lack of competition.
Comment
-
Comment