Video Memory stress Test v1.7/1.21: вопросы, ответы, анонсы
Модераторы: max-sever, iStalker, andser
-
- Участник
- Сообщения: 532
- Зарегистрирован: 06.06.2005 3:29
- Откуда: Недалеко от Киева
- Контактная информация:
-
- Администратор Judge Dredd
- Сообщения: 17062
- Зарегистрирован: 17.01.2003 11:52
- Контактная информация:
Тем не менее, парни из OCCT развивают свой тест видеопамяти именно на CUDA - http://www.ocbase.com/forum/viewtopic.php?f=6&t=49#p162 . Врпрочем, по-моему они вляпались в другую яму - они обнаруживают ошибки с помощью шейдерного кода, исполняющегося на GPU, но если сбоит сам GPU, их код может выдавать false-positives и упускать настоящие ошибки. В этом отношении обнаружение ошибок на CPU, как в вашем тесте, куда надежнее.
-
- Участник
- Сообщения: 532
- Зарегистрирован: 06.06.2005 3:29
- Откуда: Недалеко от Киева
- Контактная информация:
-
- Участник
- Сообщения: 756
- Зарегистрирован: 12.01.2005 9:16
- Откуда: Moscow
- Контактная информация:
похоже, как только они найдут как протестировать, так нвидиа станет их (2ю память) и в играх использовать.misha mike писал(а):DrEvil, сколько видеопамяти этим товарищам удается простестировать? У мнея нет GF8xxx/9xxx, но если им как-то удалось захапать всю память, то я готов возобновить работу над CUDA.
вообще, мне до сих не понятно, что так мешает её использовать.
-
- Участник
- Сообщения: 532
- Зарегистрирован: 06.06.2005 3:29
- Откуда: Недалеко от Киева
- Контактная информация:
Что-то я не понял полета мысли. Видеопамять и так во всю используется в играх, т.с. по прямому назначению.volkodav писал(а):похоже, как только они найдут как протестировать, так нвидиа станет их (2ю память) и в играх использовать.
Когда я активно работал в этом направлении, я пришел к такому выводу, что около 50 мегабайт резервируется либо для внутреннего использования самим GPU, либо для некоего библиотечного кода. А с некоторыми версиями драйверов к тому же, после достижения предела памяти, вся библиотека CUDA оказывается в нерабочем состоянии и ее нужно повторно инициализировать.вообще, мне до сих не понятно, что так мешает её использовать.
Не все так просто, память реально занята будет вся. Вопрос в том, какая ее часть занята именно тестом. А это вообще непонятно как определить.DrEvil писал(а):Вы таки будете смеяться, но на тестовой 8800 GT их GPU:Memtest написал, что протестировал все 512 Мб. Попробую найти карточку с гигабайтом и заодно проверить мониторингом RT действительное потребление, а то на заборе тоже написано...
-
- Участник
- Сообщения: 756
- Зарегистрирован: 12.01.2005 9:16
- Откуда: Moscow
- Контактная информация:
misha mike, видимо, я не верно донёс мысль)
я говорил про использование памяти 2ой видяхи в сли.
Если я правильно понимаю, сли использует мощности обоих гпу, но память одной.
во всяком случае, по большинству тестов, что я видел, везде писали про сли, мол "упирается в память одной видяхи".
впрочем, могу ошибаться, и данная проблема давно решена.
я говорил про использование памяти 2ой видяхи в сли.
Если я правильно понимаю, сли использует мощности обоих гпу, но память одной.
во всяком случае, по большинству тестов, что я видел, везде писали про сли, мол "упирается в память одной видяхи".
впрочем, могу ошибаться, и данная проблема давно решена.
-
- Участник
- Сообщения: 532
- Зарегистрирован: 06.06.2005 3:29
- Откуда: Недалеко от Киева
- Контактная информация:
volkodav, если речь именно о SLI, то в такой конфигурации всегда используются оба GPU и обе памяти. Вот только содержимое памяти обоих адаптеров полностью идентично. Так как оба ядра работают над одной сценой, то значит наборы текстур, шейдеров и вершин должны быть одинаковыми. Теоретически можно использовать память каждой карты отдельно, удвоив в итоге доступный обем, но в таком случае видеокартам прийдется постоянно лезть в память друг к другу за теми данными, которых нет в локальной памяти. Но это настолько медленно, что такой SLI никому не нужен будет. Так что SLI теоретически удваивает только вычислительную мощность, но не память.
Фраза "упирается в память одной видяхи" еще может касаться конфигурации с видеокартами с разным объемом памяти. В этом случае более "емкая" видеокарта вынуждена подстраиваться под менее "емкую", используя только часть своей локальной видеопамяти.
Фраза "упирается в память одной видяхи" еще может касаться конфигурации с видеокартами с разным объемом памяти. В этом случае более "емкая" видеокарта вынуждена подстраиваться под менее "емкую", используя только часть своей локальной видеопамяти.
-
- Участник
- Сообщения: 532
- Зарегистрирован: 06.06.2005 3:29
- Откуда: Недалеко от Киева
- Контактная информация:
Скачал сегодня CUDA SDK 2.1, почитал доку... Не понимаю зачем нужно было давать этой версии номер 2.1, когда изменения не тянут более чем на 1.3. Driver API по-прежнему документирован очень скудно, и хотя с одной стороны, количество примеров использования Driver API по сравнению с версией 1.1 увеличелось на 50%, но с другой стороны, их там ведь было всего два. Ага, теперь их аж три. Из 66.
Ребята из nVidia, похоже, вообще в серьез не воспринимают мысль, что под Windows кто-то может программить не на MSVC, а под Linux -- не на GCC. Эмуляции Driver API по-прежнему нет, а значит все, кто не пользуется единственно "правильными" компиляторами, по-человечески отлаживать GPU-код не могут. А если у программиста нет еще и "правильной" видеокарты, то он вообще никак не может проверить работоспособность написанного им кода в том виде, в котором этому коду предстоит выполняться на машине клиента.
Одно хорошо, использованное в тесте подмножество API осталось баз изменений, а это значит что VMT будет использовать CUDA 2.1, если таковой имеется на машине пользователя. Единственное что тут можно сделать, так это перекомпилировать GPU-код теста новой версией компилятора NVCC. Не знаю что там изменилось, но выкладываю новый файл тут. Его достаточно просто распаковать и подбросить в каталог текущей версии VMT, после чего он будет использоваться вместо "зашитого" в программу кода старой версии. Если у кого есть возможность, протестируйте плиз.
Ребята из nVidia, похоже, вообще в серьез не воспринимают мысль, что под Windows кто-то может программить не на MSVC, а под Linux -- не на GCC. Эмуляции Driver API по-прежнему нет, а значит все, кто не пользуется единственно "правильными" компиляторами, по-человечески отлаживать GPU-код не могут. А если у программиста нет еще и "правильной" видеокарты, то он вообще никак не может проверить работоспособность написанного им кода в том виде, в котором этому коду предстоит выполняться на машине клиента.
Одно хорошо, использованное в тесте подмножество API осталось баз изменений, а это значит что VMT будет использовать CUDA 2.1, если таковой имеется на машине пользователя. Единственное что тут можно сделать, так это перекомпилировать GPU-код теста новой версией компилятора NVCC. Не знаю что там изменилось, но выкладываю новый файл тут. Его достаточно просто распаковать и подбросить в каталог текущей версии VMT, после чего он будет использоваться вместо "зашитого" в программу кода старой версии. Если у кого есть возможность, протестируйте плиз.
-
- Администратор Judge Dredd
- Сообщения: 17062
- Зарегистрирован: 17.01.2003 11:52
- Контактная информация:
Что ж, получилось очень любопытно. Память вообще почти не занимается при прогоне теста. Такое ощущение, что они гоняют сравнительно небольшое окно по всему объему. Они определенно знают какое-то интересное кун-фупамять реально занята будет вся. Вопрос в том, какая ее часть занята именно тестом
Это вы еще доку OpenCL не читали...почитал доку...
Кстати, изменения в ожидаемой CUDA 2.2 - http://forums.nvidia.com/index.php?showtopic=92416 , может что полезное увидите.
-
- Участник
- Сообщения: 532
- Зарегистрирован: 06.06.2005 3:29
- Откуда: Недалеко от Киева
- Контактная информация:
Даже не представляю как таким способом можно проверить всю видеопамять. Функций выделения памяти на устройстве три штуки, и ни одна из них не позволяет программисту влиять на место, в котором память выделяется. Перемещать выделенный блок вообще нельзя. Поэтому рулить окном не выйдет.DrEvil писал(а):Что ж, получилось очень любопытно. Память вообще почти не занимается при прогоне теста. Такое ощущение, что они гоняют сравнительно небольшое окно по всему объему. Они определенно знают какое-то интересное кун-фу
Единственное, что может быть, они вообще память не выделяют, а бегают по ней "как есть". Я не могу проверить, будут ли в таком случае генерироваться AV-исключения, но мне такой путь кажется весьма рискованным даже если оригинальное содержимое памяти будет полностью восстановлено.
В принципе, живут же тесты системной памяти типа S&M, которые даже не пытаются протестировать все что есть, и никто особо не плачет.
Немного ознакомился, наследует традиции OpenGL и на беглый взгляд еще меньше подходит для тестирования из-за своей платформонезависимости.Это вы еще доку OpenCL не читали...почитал доку...
С точки зрения тестирования памяти, мало интересного.Кстати, изменения в ожидаемой CUDA 2.2 - http://forums.nvidia.com/index.php?showtopic=92416 , может что полезное увидите.
-
- Новичок
- Сообщения: 4
- Зарегистрирован: 05.05.2009 14:47
- Откуда: Москва
- Контактная информация:
Изменение видеорежима на 640x480x16...ОШИБКА (Код: -1)
[06.05.2009 14:57:53] Начало тестирования "Первичный видеодрайвер ()"...
Попытка инициализации 16bpp RGB:565...НЕ ПОДДЕРЖИВАЕТСЯ (Код: 88760233)
Попытка инициализации 16bpp RGB:555...НЕ ПОДДЕРЖИВАЕТСЯ (Код: 88760233)
Попытка инициализации 16bpp BGR:565...НЕ ПОДДЕРЖИВАЕТСЯ (Код: 88760233)
Попытка инициализации 32bpp RGB:888...НЕ ПОДДЕРЖИВАЕТСЯ (Код: 88760233)
Попытка инициализации 32bpp BGR:888...НЕ ПОДДЕРЖИВАЕТСЯ (Код: 88760233)
НЕТ УСЛОВИЙ ДЛЯ ТЕСТИРОВАНИЯ
вот что пишит
[06.05.2009 14:57:53] Начало тестирования "Первичный видеодрайвер ()"...
Попытка инициализации 16bpp RGB:565...НЕ ПОДДЕРЖИВАЕТСЯ (Код: 88760233)
Попытка инициализации 16bpp RGB:555...НЕ ПОДДЕРЖИВАЕТСЯ (Код: 88760233)
Попытка инициализации 16bpp BGR:565...НЕ ПОДДЕРЖИВАЕТСЯ (Код: 88760233)
Попытка инициализации 32bpp RGB:888...НЕ ПОДДЕРЖИВАЕТСЯ (Код: 88760233)
Попытка инициализации 32bpp BGR:888...НЕ ПОДДЕРЖИВАЕТСЯ (Код: 88760233)
НЕТ УСЛОВИЙ ДЛЯ ТЕСТИРОВАНИЯ
вот что пишит
-
- Участник
- Сообщения: 532
- Зарегистрирован: 06.06.2005 3:29
- Откуда: Недалеко от Киева
- Контактная информация:
Всё просто... На мой взгляд глупо ждать по несколько часов, пока память протестится, только ради того, чтоб получить ответ "ДА- на видюхе битая память". Это по глюкам в марке/играх определить не сложно (глюки проца и памяти имеют разный вид, если конечно не глюк контроллера памяти, который и эта прога опознает как битую память)... Есть более продвинутые, быстрые и точные методы выявления неисправностей.
Вобщем если видюха артефачит- неси в сервис (либоо ремонтируй, если умеешь).... Если ремонтировать человек не умеет какой смысл выявлять причину артефактов??? (причём недостаточную для локализации неисправности)...
Думаю этого обоснования достаточно??...
PS Лично я не против такого ПО (обсирать не хотел, просто пытался высказать своё мнение), но для кого оно??? Ели оно для ремонтников так неплохо, чтоб определялся конкретный битый модуль памяти. Если для пользователя, так чтоб какой-то эффект был, надо добавить функцию блокировки допустим дохлого модуля/отключения доступа к конкретным (битым) адресам видеопамяти.. не уверен, что это возможно под Windows (т.к. не програмист), но тогда бы программе "цены не было"...
Вобщем если видюха артефачит- неси в сервис (либоо ремонтируй, если умеешь).... Если ремонтировать человек не умеет какой смысл выявлять причину артефактов??? (причём недостаточную для локализации неисправности)...
Думаю этого обоснования достаточно??...
PS Лично я не против такого ПО (обсирать не хотел, просто пытался высказать своё мнение), но для кого оно??? Ели оно для ремонтников так неплохо, чтоб определялся конкретный битый модуль памяти. Если для пользователя, так чтоб какой-то эффект был, надо добавить функцию блокировки допустим дохлого модуля/отключения доступа к конкретным (битым) адресам видеопамяти.. не уверен, что это возможно под Windows (т.к. не програмист), но тогда бы программе "цены не было"...
-
- Администратор Judge Dredd
- Сообщения: 17062
- Зарегистрирован: 17.01.2003 11:52
- Контактная информация:
Yurik
Знать бы для начала, как там у NVIDIA работа с видеопамятью устроена. Есть немало историй, из которых следует, что там все очень непросто устроено. Например, человек отрывал модуль памяти от платы, а обнаруживаемый картой объем уменьшался отнюдь не на емкость этого модуля, и вообще не пропорционально емкости модулей.неплохо, чтоб определялся конкретный битый модуль памяти
-
- Участник
- Сообщения: 532
- Зарегистрирован: 06.06.2005 3:29
- Откуда: Недалеко от Киева
- Контактная информация:
Я не буду тут оправдываться. Скажу лишь, что данная программа писалась в рамках однажды открытого мной сервисного центра по ремонту компьютеров. Писалась в первую очередь для себя, но от того что я пустил ее в свободное плавание никому хуже не станет. Цель ее -- потоковое тестирование видеопамяти без обязательного участия впялившегося очками в монитор надзирателя (посмотрел бы я на уважаемого Юрика, как он тестирует одновременно три видюхи путем визуального поиска артефактов в 3D-марке). Выводимая программой информация дает опытному человеку достаточно много информации о причине артефактов, а лог загрузочной версии вообще дает реальные физические адреса сбойных участков. А вот нужна программа кому-нибудь или нет, пусть каждый решает сам, никто никому ничего не навязывает. Тем более что программа благополучно пережила породивший ее сервис-центр и пользуется не в пример большей популярностью (за что отдельное спасибо сайту nvworld.ru).
-
- Участник
- Сообщения: 532
- Зарегистрирован: 06.06.2005 3:29
- Откуда: Недалеко от Киева
- Контактная информация:
-
- Новичок
- Сообщения: 6
- Зарегистрирован: 25.06.2009 22:04
- Откуда: Россия
- Контактная информация:
Всегда старался ставить дрова поновее. В играх были жуткие артефакты. Вчера залез на этот форум. После прочтения нескольких тем решил поставить старые дрова.
Начал с 169-ых. Артефакты исчезли.
Но вот в игрушке TRON 2.0 графика виснет минут через 5-7 (до этого не висла). Тем не менее звук идет и комп даже на клавиатуру реагирует. Помогает только ребут.
На диске от видюхи дрова версий (71.84, 77.72, 77.74, 77.77, 78.01). Пробовал ставить два первых и самый последний. Время игры до зависания менялось от 5 минут до 30, но все равно висло.
Карточку сам не разгонял, но частоты у нее следующие: Ядро - 400, Память - 500. Насколько я понял, это "не родные". Может потому что карточка от GIGABYTE.
В furMark'e никаких артефактов не заметил.
Когда Mideo Vemory stress Test закончился, было 43 тысячи ошибок.
Лог:
Начал с 169-ых. Артефакты исчезли.
Но вот в игрушке TRON 2.0 графика виснет минут через 5-7 (до этого не висла). Тем не менее звук идет и комп даже на клавиатуру реагирует. Помогает только ребут.
На диске от видюхи дрова версий (71.84, 77.72, 77.74, 77.77, 78.01). Пробовал ставить два первых и самый последний. Время игры до зависания менялось от 5 минут до 30, но все равно висло.
Карточку сам не разгонял, но частоты у нее следующие: Ядро - 400, Память - 500. Насколько я понял, это "не родные". Может потому что карточка от GIGABYTE.
В furMark'e никаких артефактов не заметил.
Когда Mideo Vemory stress Test закончился, было 43 тысячи ошибок.
Лог:
Код: Выделить всё
Изменение видеорежима на 640x480x16...OK
[26.06.2009 12:54:40] Начало тестирования "Первичный видеодрайвер (NVIDIA GeForce 6600)"...
Попытка инициализации 16bpp RGB:565...OK
Ошибка в [074B1C00]: должно быть FFFF, однако найдено 0000 (биты: 1111111111111111)
Ошибка в [074B1C02]: должно быть FFFF, однако найдено 0000 (биты: 1111111111111111)
Ошибка в [074B1C04]: должно быть FFFF, однако найдено 0000 (биты: 1111111111111111)
Ошибка в [074B1C06]: должно быть FFFF, однако найдено 0000 (биты: 1111111111111111)
Ошибка в [0756F000]: должно быть FFFF, однако найдено 0000 (биты: 1111111111111111)
Ошибка в [0756F002]: должно быть FFFF, однако найдено 0000 (биты: 1111111111111111)
Ошибка в [0756F004]: должно быть FFFF, однако найдено 0000 (биты: 1111111111111111)
Ошибка в [0756F006]: должно быть FFFF, однако найдено 0000 (биты: 1111111111111111)
Ошибка в [07344C00]: должно быть FFFF, однако найдено 0000 (биты: 1111111111111111)
Ошибка в [07344C02]: должно быть FFFF, однако найдено 0000 (биты: 1111111111111111)
Ошибка в [07344C04]: должно быть FFFF, однако найдено 0000 (биты: 1111111111111111)
Ошибка в [07344C06]: должно быть FFFF, однако найдено 0000 (биты: 1111111111111111)
Ошибка в [07141000]: должно быть FFFF, однако найдено 0000 (биты: 1111111111111111)
Ошибка в [07141002]: должно быть FFFF, однако найдено 0000 (биты: 1111111111111111)
Ошибка в [07141004]: должно быть FFFF, однако найдено 0000 (биты: 1111111111111111)
Ошибка в [07141006]: должно быть FFFF, однако найдено 0000 (биты: 1111111111111111)
Ошибка в [0714A000]: должно быть FFFF, однако найдено 0000 (биты: 1111111111111111)
Ошибка в [0714A002]: должно быть FFFF, однако найдено 0000 (биты: 1111111111111111)
Ошибка в [0714A004]: должно быть FFFF, однако найдено 0000 (биты: 1111111111111111)
Ошибка в [0714A006]: должно быть FFFF, однако найдено 0000 (биты: 1111111111111111)
Ошибка в [07268C00]: должно быть FFFF, однако найдено 2D77 (биты: 1101001010001000)
Ошибка в [07268C02]: должно быть FFFF, однако найдено 002A (биты: 1111111111010101)
Ошибка в [07268C04]: должно быть FFFF, однако найдено 1E65 (биты: 1110000110011010)
Ошибка в [07268C06]: должно быть FFFF, однако найдено 0020 (биты: 1111111111011111)
Ошибка в [0702D000]: должно быть FFFF, однако найдено 3443 (биты: 1100101110111100)
Ошибка в [0702D002]: должно быть FFFF, однако найдено 001B (биты: 1111111111100100)
Ошибка в [0702D004]: должно быть FFFF, однако найдено 3443 (биты: 1100101110111100)
-
- Участник
- Сообщения: 532
- Зарегистрирован: 06.06.2005 3:29
- Откуда: Недалеко от Киева
- Контактная информация:
-
- Участник
- Сообщения: 532
- Зарегистрирован: 06.06.2005 3:29
- Откуда: Недалеко от Киева
- Контактная информация: