| 1.2, Аноним (-), 00:05, 28/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –16 +/– | |
> Первый выпуск ветки Mesa 18.0.0 имеет экспериментальный статус - после проведения окончательной стабилизации кода будет выпущена стабильная версия 18.0.1.
С чего вы вообще такую информацию взяли?! Сами придумали?
Mesa 18.0.0 - это стабильная версия! Не экспериментальный статус, а именно стабильный!
| | |
| |
| 2.3, Аноним (-), 00:12, 28/03/2018 [^] [^^] [^^^] [ответить]
| +13 +/– | |
> С чего вы вообще такую информацию взяли?! Сами придумали?
Всегда так было, первый релиз Mesa экспериментальный со стабилизацией в последующем выпуске.
https://cgit.freedesktop.org/mesa/mesa/tree/docs/relnotes/
"Mesa 18.0.0 is a new development release. People who are concerned with stability and reliability should stick with a previous release or wait for Mesa 18.0.1"
| | |
|
| 1.4, Андрей (??), 05:21, 28/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
> В драйвере r600 реализована поддержка OpenGL 4.3 и OpenGL ES 3.1 для GPU Evergreen с блоком вычислений с двойной точностью FP64 (например, HD 5800 и HD 6900);
Начал читать, и улыбка стала расползаться по лицу. Закончил - и улыбка сползла. Продолжаем ожидать эмуляцию на HD 5700.
| | |
| |
| 2.5, iPony (?), 07:07, 28/03/2018 [^] [^^] [^^^] [ответить]
| –3 +/– | |
Так-то читаешь, и особо не понимаешь в этих названиях.
> Продолжаем ожидать эмуляцию на HD 5700 (2009 год)
Ждите :)
| | |
| 2.8, Аноним (-), 08:45, 28/03/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Продолжаем ожидать эмуляцию
Какой в ней смысл, если всё равно будет тормозить?
| | |
| |
| 3.10, Аноним (-), 09:46, 28/03/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
>> Продолжаем ожидать эмуляцию
> Какой в ней смысл, если всё равно будет тормозить?
Смысл в том что все остальные фичи для 4.0 (и аж до 4.4) давно реализованы, и один только FP64 на большинстве Evergreen держит на 3.3.
| | |
|
| 2.9, Аноним (-), 09:40, 28/03/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
>> В драйвере r600 реализована поддержка OpenGL 4.3 и OpenGL ES 3.1 для GPU Evergreen с блоком вычислений с двойной точностью FP64 (например, HD 5800 и HD 6900);
> Начал читать, и улыбка стала расползаться по лицу. Закончил - и улыбка
> сползла. Продолжаем ожидать эмуляцию на HD 5700.
Тоже не понимаю чего они тянут, первые патчи были чуть ли не год назад ещё.
| | |
|
| |
| 2.12, Megabit (ok), 10:30, 28/03/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
 Хватит уже издеваться над своим стареньким "тонким клентом" - дай дорогу уже молодым железякам... )))
| | |
| 2.13, iPony (?), 10:35, 28/03/2018 [^] [^^] [^^^] [ответить]
| +/– | |
Вот действительно, указывали бы года в скобочках, а то какие-то цифробуквы не понтяные
> ATI Radeon Xpress 1250 (2006 год) | | |
|
| 1.7, JimHevens (?), 08:11, 28/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Для драйвера i965 реализована система кэширования шейдеров на диске
Лютая годнота.
| | |
| |
| 2.15, iZEN (ok), 11:20, 28/03/2018 [^] [^^] [^^^] [ответить]
| –8 +/– |
 Mesa не будет без них работать. В довесок к видеодрайверам нужен обязательно гиг ллвм-шланга. А иначе как? Так завещали Intel и AMD своим подопечным в X.org, когда протаскивали свои идеи в жизнь, и выбрасывали оттуда всяких ненужных бздунов, макосников и солярщиков, чтобы не мешались под ногами и не имели права голоса. Запомните: посредственность правит миром.
| | |
| |
| 3.16, Led (ok), 11:37, 28/03/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
 > В довесок к видеодрайверам нужен обязательно гиг ллвм-шланга.
Хорош уже по 20-у разу звездеть про "гиг", недалёкое.
| | |
| 3.18, Ne01eX (ok), 12:02, 28/03/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
 > Mesa не будет без них работать. В довесок к видеодрайверам нужен обязательно
> гиг ллвм-шланга. А иначе как? Так завещали Intel и AMD своим
> подопечным в X.org, когда протаскивали свои идеи в жизнь, и выбрасывали
> оттуда всяких ненужных бздунов, макосников и солярщиков, чтобы не мешались под
> ногами и не имели права голоса. Запомните: посредственность правит миром.
1. В следующий раз, прежде чем что-то покупать из железа, поинтересуйтесь что вы покупаете. И покупайте, то что вам действительно нужно.
2. LLVM 6.0.0 весь целиком в распакованном виде весит 636 МБ в сборке для i586 и 709 Мб в сборке для x86_64. Это я говорю о сборках полностью готовых к кросскомпиляции, включая TARGET Windows-платформы и упомянутых вами, бздунов, солярщиков и макосников. + Ещё инструменты для отладки... ещё какая-то хeрня, которой я никогда не пользуюсь... Стоп. Ладно пaцaны, я пошёл что-нибудь выкушу из этого LLVM, всё равно не пользуюсь...
| | |
| |
| 4.22, iZEN (ok), 12:44, 28/03/2018 [^] [^^] [^^^] [ответить]
| –4 +/– | |
> 1. В следующий раз, прежде чем что-то покупать из железа, поинтересуйтесь что вы покупаете. И покупайте, то что вам действительно нужно.
Спасибо за совет. Но как быть тем, кто покупал железо, когда ещё не было LLVM/Clang, оно "прилетело" только через несколько лет после покупки, насильно и безальтернативно, а новое железо без этого не может уже работать?
| | |
| 4.39, iZEN (ok), 21:00, 28/03/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > 2. LLVM 6.0.0 весь целиком в распакованном виде весит 636 МБ в
> сборке для i586 и 709 Мб в сборке для x86_64.
% pkg info llvm60-6.0.0
llvm60-6.0.0
Name : llvm60
Version : 6.0.0
Installed on : Wed Mar 28 20:51:16 2018 MSK
Origin : devel/llvm60
Architecture : FreeBSD:11:amd64
Prefix : /usr/local
Categories : devel lang
Licenses : LLVM
Maintainer : brooks@FreeBSD.org
WWW : http://llvm.org/
Comment : LLVM and Clang
Options :
CLANG : on
COMPILER_RT : on
DOCS : off
EXTRAS : on
GOLD : off
LIT : on
LLD : on
LLDB : off
OPENMP : on
Shared Libs required:
libedit.so.0
libxml2.so.2
Shared Libs provided:
libclang_rt.ubsan_standalone-x86_64.so
libLTO.so.6
libclang_rt.ubsan_minimal-x86_64.so
libLLVM-6.0.so
libclang_rt.dyndd-x86_64.so
libclang.so.6
libomptarget.so
libomp.so
libclang_rt.asan-x86_64.so
Annotations :
FreeBSD_version: 1101512
Flat size : 690MiB
Description :
The LLVM Project is a collection of modular and reusable compiler and
toolchain technologies.
This port includes Clang (a C/C++/Objective-C compiler), LLD (a linker),
LLDB (a debugger), an OpenMP runtime library, and the LLVM infrastructure
these are built on.
WWW: http://llvm.org/
| | |
|
|
| 2.17, Ne01eX (ok), 11:43, 28/03/2018 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Не того желаете, молодой чемодан. На текущий момент Mesa _собирается_ GCC, если только вам не нужен radv (Radeon'ы с их Вулканами).
То есть, если у вас видеокарточка не Radeon, то вы можете тихо бздеть и ненавидеть clang, спокойно собирая Mesa с помощью GCC. Для этого достаточно указаать опции
--disable-llvm \
--disable-llvm-shared-libs \
И даже переменные CC и CXX выставлять не надо.
На текущий момент у меня нет карточек Radeon ни на одной платформе, но я всё равно собираю Mesa с помощью clang. Ну, потому что мне так никто на форуме ни разу не объяснил, - почему я должен ненавидеть clang. Методичек мне тоже никто уже давно не высылает. А сидеть бздеть и тихо ненавидеть что-то без причины я пока не умею.
Более того, я у себя время от времени собираю ПО то одним, то другим. GCC почти всегда выигрывает, но это не повод для ненависти.
Кроме этого, я где-то интересовался на форуме, в каком конкретно ПО clang/clang++ дерут gcc g++, но тоже ничего внятного не услышал.
В общем, у меня пока живут оба. :-)
| | |
| |
| |
| 4.23, AlphabetDoc (?), 12:55, 28/03/2018 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> GCC в сравнении с LLVM/Clang порождает на 15-20% более жирный код
Воу, кошмар какой, пора менять 4 гб флешку на 8 гб.
| | |
| |
| 5.26, iZEN (ok), 13:38, 28/03/2018 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> А работает какой быстрее?
Тормозят одинаково, но GCC поприятнее.
| | |
| 5.27, Ne01eX (ok), 13:40, 28/03/2018 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> А работает какой быстрее?
Я не знаю у кого как, но у меня получается при компиляции
на i586 с флагами -O2 -march=i586 -mtune=i686
на x86_64 с флагами -O2 -fPIC
с GCC код [b]_почти всегда_[/b] меньше и [b]_почти всегда_[/b] быстрее.
С флагами -O3 код результат становится жирнее везде, так как разворачиваются циклы и т.п.
С флагом -Ofast (короткий аналог для кучи других флагов) LLVM иногда тупо давится.
Но так как мне это и не нужно, то я просто не использует эти флаги, ограничившись -O2.
Кстати, если для вас критичен размер, то -Os вам в помощь. Одинаково хорошо работает как с GCC, так и clang.
У меня нет специальных исскуственных тестилок (буду рад, если кто-то поделится ссылкой), размер я определяю на глазок по факту, собрав одно и тоже сначала с GCC, а потом с LLVM, а производительность определяю исходя из задач, поставленных перед ПО. Ну, например, - если это архиватор, то просто замеряю время запаковки/распаковки.
P.S. Не разу не замерял точное время сборки, но субъективно LLVM всегда собирает медленнее, чем GCC. В принципе, я это не расцениваю как недостаток, - мне важнее результат.
P.P.S. В контексе Mesa - как раз тот случай, когда clang выигрывает у GCC. Даже если вы не собираете её с поддержкой RADV. Благо, здесь есть цветные картинки с попугаями и посмотреть/убедится в этом может каждый.
| | |
| |
| 6.30, Elon Musk (?), 14:08, 28/03/2018 [^] [^^] [^^^] [ответить]
| –3 +/– |
Ибо у тебя libc тоже собран с имплантами (build-in gcc) так что не меси чущь, когда пол ядерной системы висит на gcc рантайме.
| | |
| |
| 7.34, Ne01eX (ok), 19:31, 28/03/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Ибо у тебя libc тоже собран с имплантами (build-in gcc) так что
> не меси чущь, когда пол ядерной системы висит на gcc рантайме.
1. Что меня всегда поражало в анонимных аналитиках, так их "сверхразвитые телепатические способности".
2. Ты так это сказал, как буд-то это что-то плохое.
При прочих равных, я всегда буду топить за GNU решения. Я думаю, это понятно и объяснять почему - не надо. Но [b]я всегда за объективность, так как мне ещё и результат важен[/b]. А войнушки ваши лицензионные для детей оставьте.
Но в данном случае ты попал пальцем в небо. У меня glibc не пользует ничего от gcc на обеих архитектурах. Вывод ldd надо?
| | |
|
|
|
|
| |
| |
| 5.35, Ne01eX (ok), 20:09, 28/03/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Опечатка не геймеров, шейдеров
МБ - Шредера? Тогда зачем во множественном числе?
| | |
|
|
|
| 2.28, Аноним (-), 13:50, 28/03/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
Ну вот когда GCC научится шейдеры компилировать, тогда и будет такой форк.
| | |
| |
| 3.29, Ne01eX (ok), 13:52, 28/03/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Ну вот когда GCC научится шейдеры компилировать, тогда и будет такой форк.
Типа gcc-brig?
| | |
|
|
| 1.33, J.L. (?), 18:58, 28/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 > DXVK ... нацеленного на создание реализации ... Direct3D 11 поверх API Vulkan
а Direct3D 9 оно реализует/будет ?
| | |
| |
| |
| |
| 4.45, Аноним (-), 16:29, 29/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
Да, оно всё ещё в разработке и до DXVK далеко, но надеемся что автор будет таким же активным как и doitsujin
| | |
|
|
| 2.44, Аноним (-), 12:47, 29/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
Direct3D 9 реализован в самой Mesa, для него не нужны никакие врапперы. Только вот Wine, видимо, в силу каких-то корыстных интересов, отказывается принимать поддержку нативного D3D9 в апстрим.
| | |
| |
| 3.46, J.L. (?), 12:27, 30/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Direct3D 9 реализован в самой Mesa, для него не нужны никакие врапперы.
> Только вот Wine, видимо, в силу каких-то корыстных интересов, отказывается принимать
> поддержку нативного D3D9 в апстрим.
я пользуюсь wine-nine из ppa, присутствуют артефакты в играх (например в героях5), может из-за дров, может из-за вайннайна - хотелось бы попробовать альтернативу
хм, давно не пробовал простой вайн, надо бы посмотреть есть ли в нём артефакты в тех же героях5 (дааавно, много вайнов и версий месы назад - были, но с другой стороны в найне артефакты визуально не менялись с тех пор)
| | |
|
|
| 1.38, VINRARUS (ok), 20:55, 28/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 FreeSync через hdmi в каком тысячелетии ждать для GCN?
Да я знаю шо тут АМДа виновата, но может можна без неё обойтись?
| | |
| 1.41, рара Кен (?), 22:38, 28/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 ну вот! замечательно! просто слов нет как все здорово. разница всегда была лишь что в opengl один командный буфер а вулкан много в остальном та же организация построенная на расширениях. арм - независимые от платформ, скажем nvx поддерживаются на Maxwell 2 поколения и Pascale.
| | |
| |
| 2.42, Ne01eX (ok), 00:44, 29/03/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
> ну вот! замечательно! просто слов нет как все здорово. разница всегда была
> лишь что в opengl один командный буфер а вулкан много в
> остальном та же организация построенная на расширениях. арм - независимые от
> платформ, скажем nvx поддерживаются на Maxwell 2 поколения и Pascale.
Вы так говорите, как буд-то в Windows всё по-другому. Только Mesa научилась всё сводить к единому знаменателю, а в Windows как был бардак с драйверами, так и есть.
| | |
|
|
