AMDGPU-Pro 17,40 с поддержкой больших страниц | Биткоин форум

		Биткоин Форум > - Mining (Altcoins)
AMDGPU-Pro 17,40 с поддержкой больших страниц

5 ноября 2017, 3:04:33 PM	# 1
nerdralph Сообщения: 420 Цитировать по имени цитировать ответ	Re: AMDGPU-Pro 17,40 с поддержкой больших страниц Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru http://support.amd.com/en-us/kb-articles/Pages/AMDGPU-PRO-Driver-for-Linux-Release-Notes.aspx Любой проверить его еще на карточке с настраиваемой BIOS? Я был смущен комментарием о размере страницы, так как претензии AMD GCN Whitepaper "Как и кэш данных L1, L2 практически решены, поэтому никаких Буферы TLB не требуется вообще" на стр 10. https://www.amd.com/Documents/GCN_Architecture_whitepaper.pdf Однако переменный размер страницы для контроллера кэша предлагает TLB, и комментарии по Phoronix, кажется, подтверждают это: https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/977778-amdgpu-increasing-fragment-size-for-performance Я предполагаю, что это просто еще один пример того, почему документы GCN не может быть 100% полагаться, и выяснить, что происходит на самом деле нужно пройти через код драйвера и сделать свои собственные хитрости и тестирование.

Как заработать Биткоины?
Без вложений. Не майнинг.

5 ноября 2017, 9:22:26 PM	# 2
Бриджмена Сообщения: 2 Цитировать по имени цитировать ответ	Re: AMDGPU-Pro 17,40 с поддержкой больших страниц Получил 1806 Биткоинов Реальная история. котировка Я был смущен комментарием о размере страницы, так как претензии AMD GCN Whitepaper "Как и кэш данных L1, L2 практически решены, поэтому никаких Буферы TLB не требуется вообще" на стр 10. https://www.amd.com/Documents/GCN_Architecture_whitepaper.pdf Это замечание относится не требуют буферов TLB для того, чтобы получить доступ к оперативной памяти тегов и увидеть, если есть попадание в кэше, поэтому запросы, которые попали в кэше немного быстрее. Если промахи доступа в кэше, то запрос должен пройти через таблицу страниц (ускоренную с помощью буферов TLB) для того, чтобы получить доступ к правильной ячейке памяти.

6 ноября 2017, 7:18:08 PM	# 3
nerdralph Сообщения: 420 Цитировать по имени цитировать ответ	Re: AMDGPU-Pro 17,40 с поддержкой больших страниц Цитата: Бриджмен от 05 ноября 2017 г., 9:22:26 PM котировка Я был смущен комментарием о размере страницы, так как претензии AMD GCN Whitepaper "Как и кэш данных L1, L2 практически решены, поэтому никаких Буферы TLB не требуется вообще" на стр 10. https://www.amd.com/Documents/GCN_Architecture_whitepaper.pdf Это замечание относится не требуют буферов TLB для того, чтобы получить доступ к оперативной памяти тегов и увидеть, если есть попадание в кэше, поэтому запросы, которые попали в кэше немного быстрее. Если промахи доступа в кэше, то запрос должен пройти через таблицу страниц (ускоренную с помощью буферов TLB) для того, чтобы получить доступ к правильной ячейке памяти. Спасибо за объяснение. Будет ли поддержка больших страниц неуместными для GCN ассемблере код, который загружает данные Uncacheable как ethash DAG с помощью FLAT_LOAD_DWORD с SLC и GLC бит установлен? По обходя L1 & L2, что должно означать пропуск доступ к тегу RAM и таблицы страниц. На самом деле я не пробовал сам еще, но комментарии Wolf0 и zawawa казалось, сказать, что это было на самом деле немного медленнее.

7 ноября 2017, 3:39:45 AM	# 4
Wolf0 Сообщения: 1764 Цитировать по имени цитировать ответ	Re: AMDGPU-Pro 17,40 с поддержкой больших страниц Цитата: nerdralph от 06 ноября 2017 года, 7:18:08 PM Цитата: Бриджмен от 05 ноября 2017 г., 9:22:26 PM котировка Я был смущен комментарием о размере страницы, так как претензии AMD GCN Whitepaper "Как и кэш данных L1, L2 практически решены, поэтому никаких Буферы TLB не требуется вообще" на стр 10. https://www.amd.com/Documents/GCN_Architecture_whitepaper.pdf Это замечание относится не требуют буферов TLB для того, чтобы получить доступ к оперативной памяти тегов и увидеть, если есть попадание в кэше, поэтому запросы, которые попали в кэше немного быстрее. Если промахи доступа в кэше, то запрос должен пройти через таблицу страниц (ускоренную с помощью буферов TLB) для того, чтобы получить доступ к правильной ячейке памяти. Спасибо за объяснение. Будет ли поддержка больших страниц неуместными для GCN ассемблере код, который загружает данные Uncacheable как ethash DAG с помощью FLAT_LOAD_DWORD с SLC и GLC бит установлен? По обходя L1 & L2, что должно означать пропуск доступ к тегу RAM и таблицы страниц. На самом деле я не пробовал сам еще, но комментарии Wolf0 и zawawa казалось, сказать, что это было на самом деле немного медленнее. Медленнее действительно. одна GLC лучше. одна SLC, а также SLC + КЗС хуже, чем только КЗС. Кстати, я, наконец, решил посмотреть на то, почему Claymore-х "КАК М" Ядро для Элсмира так задница: Получите это - он на самом деле не сделать это правильно, так как в целом вещь в ASM, как он (возможно) следует. Это вывод компилятора AMD OpenCL (с использованием "-legacy" переключатель, чтобы сделать его использовать старую версию), а затем переделаны немного. Он даже использует LDS ... WTF. Он ДЕЛАЕТ воспользоваться ds_swizzle_b32, но он по-прежнему рен тратить много местных MEM записи + некоторые читает, и ds_swizzle_b32 есть (IIRC) полной скорости, но несмотря на это, он тратить 4 часов за когда это можно было бы сделать лучше. Кроме того - это заставило меня смеяться IRL - его v10.0 шахтер ищет ядро, которое не существует. Я был на самом деле Хелла запутаться в течение минуты - двойной и тройной проверили декодированный GCN файл ядра (извлеченный из памяти процесса шахтера) - но, конечно, это не было. Итак, я, наконец, понял, давайте проверим возвращаемое значение clCreateKernel () ... конечно, она возвращает CL_INVALID_KERNEL_NAME (-46). По-видимому, шахтер (очевидно) считает, что это ошибка будет нефатальной и продолжается ... но почему кровавый ебать это там?

7 ноября 2017, 7:48:39 AM	# 5
stash2coin Сообщений: 32 Цитировать по имени цитировать ответ	Re: AMDGPU-Pro 17,40 с поддержкой больших страниц Может быть какой-то тест ядра, что он удаляет до официального релиза и не потрудившись убрать ссылку на него, потому что не вызывает проблем. Еще одна забавная вещь его ЗКЕ шахтер ищет библиотеки Nvidia, но шахтер только для карт AMD

7 ноября 2017, 6:16:09 PM	# 6
nerdralph Сообщения: 420 Цитировать по имени цитировать ответ	Re: AMDGPU-Pro 17,40 с поддержкой больших страниц Цитата: Wolf0 от 07 ноября 2017 года, 3:39:45 AM Цитата: nerdralph от 06 ноября 2017 года, 7:18:08 PM Цитата: Бриджмен от 05 ноября 2017 г., 9:22:26 PM котировка Я был смущен комментарием о размере страницы, так как претензии AMD GCN Whitepaper "Как и кэш данных L1, L2 практически решены, поэтому никаких Буферы TLB не требуется вообще" на стр 10. https://www.amd.com/Documents/GCN_Architecture_whitepaper.pdf Это замечание относится не требуют буферов TLB для того, чтобы получить доступ к оперативной памяти тегов и увидеть, если есть попадание в кэше, поэтому запросы, которые попали в кэше немного быстрее. Если промахи доступа в кэше, то запрос должен пройти через таблицу страниц (ускоренную с помощью буферов TLB) для того, чтобы получить доступ к правильной ячейке памяти. Спасибо за объяснение. Будет ли поддержка больших страниц неуместными для GCN ассемблере код, который загружает данные Uncacheable как ethash DAG с помощью FLAT_LOAD_DWORD с SLC и GLC бит установлен? По обходя L1 & L2, что должно означать пропуск доступ к тегу RAM и таблицы страниц. На самом деле я не пробовал сам еще, но комментарии Wolf0 и zawawa казалось, сказать, что это было на самом деле немного медленнее. Медленнее действительно. одна GLC лучше. одна SLC, а также SLC + КЗС хуже, чем только КЗС. Кстати, я, наконец, решил посмотреть на то, почему Claymore-х "КАК М" Ядро для Элсмира так задница: Получите это - он на самом деле не сделать это правильно, так как в целом вещь в ASM, как он (возможно) следует. Это вывод компилятора AMD OpenCL (с использованием "-legacy" переключатель, чтобы сделать его использовать старую версию), а затем переделаны немного. Он даже использует LDS ... WTF. Он ДЕЛАЕТ воспользоваться ds_swizzle_b32, но он по-прежнему рен тратить много местных MEM записи + некоторые читает, и ds_swizzle_b32 есть (IIRC) полной скорости, но несмотря на это, он тратить 4 часов за когда это можно было бы сделать лучше. Кроме того - это заставило меня смеяться IRL - его v10.0 шахтер ищет ядро, которое не существует. Я был на самом деле Хелла запутаться в течение минуты - двойной и тройной проверили декодированный GCN файл ядра (извлеченный из памяти процесса шахтера) - но, конечно, это не было. Итак, я, наконец, понял, давайте проверим возвращаемое значение clCreateKernel () ... конечно, она возвращает CL_INVALID_KERNEL_NAME (-46). По-видимому, шахтер (очевидно) считает, что это ошибка будет нефатальной и продолжается ... но почему кровавый ебать это там? Спасибо за подтверждение. Таким образом, в обход L1 быстрее, но в обход L2 медленнее. Но ускорение промахов кэша L2 с большими таблицами страниц быстрее ... Согласно GCN архитектуре документов, L2 делает больше, чем просто кэш, обработки вещей, такие как глобальный Атомикс. Теперь я подозреваю, что он также участвует в организации очередей и арбитража для DRAM доступа из КС, который бы объяснить замедление с использованием SLC. Что касается Claymore, с тех пор как я впервые посмотрел на своих equihash ядер, я думал, что он хак. Он, кажется, получает большую часть своих идей от других людей, а не пытаться полностью понять аппаратный графический процессор и OpenCL компилятора. Подстройка вывода иша компилятора является то, что zawawa обсуждал в начале этого года (в дополнении к LLVM работе, чтобы получить встроенную ассемблерную работу), так что я подозреваю, клеймор только что получил идею от чтения сообщения zawawa в.

3 декабря 2017, 6:30:59 PM	# 7
Wolf0 Сообщения: 1764 Цитировать по имени цитировать ответ	Re: AMDGPU-Pro 17,40 с поддержкой больших страниц Цитата: Wolf0 от 07 ноября 2017 года, 3:39:45 AM Цитата: nerdralph от 06 ноября 2017 года, 7:18:08 PM Цитата: Бриджмен от 05 ноября 2017 г., 9:22:26 PM котировка Я был смущен комментарием о размере страницы, так как претензии AMD GCN Whitepaper "Как и кэш данных L1, L2 практически решены, поэтому никаких Буферы TLB не требуется вообще" на стр 10. https://www.amd.com/Documents/GCN_Architecture_whitepaper.pdf Это замечание относится не требуют буферов TLB для того, чтобы получить доступ к оперативной памяти тегов и увидеть, если есть попадание в кэше, поэтому запросы, которые попали в кэше немного быстрее. Если промахи доступа в кэше, то запрос должен пройти через таблицу страниц (ускоренную с помощью буферов TLB) для того, чтобы получить доступ к правильной ячейке памяти. Спасибо за объяснение. Будет ли поддержка больших страниц неуместными для GCN ассемблере код, который загружает данные Uncacheable как ethash DAG с помощью FLAT_LOAD_DWORD с SLC и GLC бит установлен? По обходя L1 & L2, что должно означать пропуск доступ к тегу RAM и таблицы страниц. На самом деле я не пробовал сам еще, но комментарии Wolf0 и zawawa казалось, сказать, что это было на самом деле немного медленнее. Медленнее действительно. одна GLC лучше. одна SLC, а также SLC + КЗС хуже, чем только КЗС. Кстати, я, наконец, решил посмотреть на то, почему Claymore-х "КАК М" Ядро для Элсмира так задница: Получите это - он на самом деле не сделать это правильно, так как в целом вещь в ASM, как он (возможно) следует. Это вывод компилятора AMD OpenCL (с использованием "-legacy" переключатель, чтобы сделать его использовать старую версию), а затем переделаны немного. Он даже использует LDS ... WTF. Он ДЕЛАЕТ воспользоваться ds_swizzle_b32, но он по-прежнему рен тратить много местных MEM записи + некоторые читает, и ds_swizzle_b32 есть (IIRC) полной скорости, но несмотря на это, он тратить 4 часов за когда это можно было бы сделать лучше. Кроме того - это заставило меня смеяться IRL - его v10.0 шахтер ищет ядро, которое не существует. Я был на самом деле Хелла запутаться в течение минуты - двойной и тройной проверили декодированный GCN файл ядра (извлеченный из памяти процесса шахтера) - но, конечно, это не было. Итак, я, наконец, понял, давайте проверим возвращаемое значение clCreateKernel () ... конечно, она возвращает CL_INVALID_KERNEL_NAME (-46). По-видимому, шахтер (очевидно) считает, что это ошибка будет нефатальной и продолжается ... но почему кровавый ебать это там? Корректирующее комментарий удален по просьбе CLAYMORE в.

5 декабря 2017, 3:38:46 AM	# 8
nerdralph Сообщения: 420 Цитировать по имени цитировать ответ	Re: AMDGPU-Pro 17,40 с поддержкой больших страниц Я просто заметил, что, хотя добыча с >2 Гб DAG быстрее 2М размер страницы, DAG время создания гораздо медленнее (3-4x дольше).

10 декабря 2017, 1:54:07 PM	# 9
Бриджмена Сообщения: 2 Цитировать по имени цитировать ответ	Re: AMDGPU-Pro 17,40 с поддержкой больших страниц Цитата: nerdralph от 06 ноября 2017 года, 7:18:08 PM Спасибо за объяснение. Будет ли поддержка больших страниц неуместными для GCN ассемблере код, который загружает данные Uncacheable как ethash DAG с помощью FLAT_LOAD_DWORD с SLC и GLC бит установлен? По обходя L1 & L2, что должно означать пропуск доступ к тегу RAM и таблицы страниц. На самом деле я не пробовал сам еще, но комментарии Wolf0 и zawawa казалось, сказать, что это было на самом деле немного медленнее. Большая поддержка страница должна еще помочь, если кэши L1 / L2 оказываются в стороне - если что-то это помогло бы больше. Игнорирование кэша L1 / L2 пропускается доступ к тегам баранам кэша, но не пропускает доступ к таблицам страниц, поэтому приведенная TLB обмолота от поддержки большой страниц все равно должен быть актуальным.

« Предыдущая тема | Следующая тема »

Как заработать Биткоины?

Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包

bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW