Про видюхи и глюки
читать дальшеКак уже писал, сделали мы апгрейд видюхи на AGP GeForce 7600GS DDR2, TV, DVI, Albatron. В целом, впечатления положительные. Только вот с самого первого запуска обнаружился неприятный глюк. Ещё на этапе запуска Хсервера были замечены мельтешащие помехи по экрану. Можно было бы списать это на наводки кабеля, только вот на прошлой видюхе такого не было. Впрочем, помехи не сильно заметные и при работе их практически не видно.
Затем, часа через 2 работы экран просто погас. Видюха перестала давать изображение, хотя сама продолжала работать, так как зависания при этом не было. Это уже гораздо серьёзнее, и причины так и не были найдены. В общем-то это повод для замены, но в дальнейшем проблема не проявилась. Правда, возможно это из за смены порта. В любом случае этот вопрос остаётся открытым.
Что же касается помех, то судя по всему, их причина найдена - видюха требует дополнительного питания в виде разъёма под стандартную колодку БП. Зачем это нужно, не совсем понятно, так как судя по тому, что индикатор нагрузки ИБП посе смены видюхи не вырос, она не отличается особо большим потреблением и если оно и выше прошлой, то ненамного. Надо будет попробовать вообще убрать питание с этого разъёма, хотя в инcтрукции сказано, что без него видюха будет ругаться.
Пока же есть подозрение, что причина помех именно в этом. Я когда-то пробовал подключать радиоприёмник без встроенного БП и фильтров к рабочему компу. Оказалось, что в цепях питания гуляют очень сильные помехи от импульсных потребителей. В первую очередь это винты и сидюки, но скорее всего, если взять осциллограф, то там обнаружится ещё много чего.
Если же у видюхи нет достаточно мощных фильтров на входе, то она все эти помехи будет благополучно собирать.
Интересно, кто-нибудь кроме нас вообще сталкивался с таким явлением на практике или хотя бы в описаниях?
Если мой предположение верно и дело в этом, то замена видюхи совершенно ничего не даст, кроме потерянного времени и затрат на поездку. В общем, будем посмотреть что с ней делать дальше...
читать дальше
@музыка:
Primordial - The Golden Spiral
@настроение:
[IMG]http://asat.science.su/smiles/draco_cool.gif[/IMG]
Относительно мельтешащих помех. Тут может быть что угодно. Вплоть до того, что это «нормальная» работа карточки. Пример. На работе у меня был Radeon7200 32Mb (раритетная вещь) все требуемое ПО работало на нем идеально. Но вот по нужде пришлось поставить GeForce 6600 128Mb. Который намного новее и дороже. Так вот, на этой карточке все тонкие линии мельтешат. Мне это сильно заметно и даже мешает, в виду особенностей работы. Ясно, что любая секретутка или геймер этого бы в жизни не заметили, но применять какое «Г» в более-менее профессиональной работе никак нельзя. имхо, радеоны всегда работали в разы лучше Жирафов, если дело касается 2Д. (3Д макс, фотошоп, прочее).
Так же сталкивался с карточкой, которая давала шум (как на плохо настроенном ящике), но там и разобраться не успели – хозяин спихнул ее какому-то чайнику.
>Зачем это нужно, не совсем понятно, так как судя по тому, что индикатор нагрузки ИБП посе смены видюхи не вырос, она не отличается особо большим потреблением и если оно и выше прошлой, то ненамного.
Тут все просто. Около 70% транзисторов современных GPU используется исключительно для одной цели – ускоритель Direct3D. На сколько мне известно, с DirectX Linux платформа, мягко говоря, не дружит, вот они и не работают. Дополнительный разъем нужен только тогда, когда включается, к примеру, трехмерная игра, набитая множеством эффектов. В 2Д режиме работает лишш малая часть GPU, соответственно потребление мизерное. Аналогично с OpenGl.
>Надо будет попробовать вообще убрать питание с этого разъёма, хотя в инcтрукции сказано, что без него видюха будет ругаться.
Когда включишш графически «тяжелую» игру – она просто отключится или зависнет, либо посыпятся артефакты, так как энергопотребление сильно увеличится.
>Если же у видюхи нет достаточно мощных фильтров на входе, то она все эти помехи будет благополучно собирать.
Как-то я случайно выломал конденсаторы фильтра питания видеокарты. Вдобавок к очень некачественному БП получилось так, что она стала зависать и засыпать экран артефактами без каких-либо причин. После смены конденсаторов все заработало как и прежде. Но это проявлялось постоянно, а не периодически.
Кстати, если вы используете DVI разъем для ЖК мониторов – аналоговых помех не может быть в принципе. Так как информация тут в монитор передается в цифровом виде.
>Если мой предположение верно и дело в этом, то замена видюхи совершенно ничего не даст, кроме потерянного времени и затрат на поездку.
Если есть запчасти со второго ПК – можно поэкспериментировать – поменять БП, видео карту, материнку.
У нас таких проблем не было ни с одной видеокартой. Может она просто была бракована в твоём примере? Вообще, при любом обычном изображении у нас нет никаких наводок, в том числе и на этой новой. Помехи можно наблюдать только лишь в одном специальном случае (см. ниже). Будь иначе, я бы с таким сидеть не смог, так как я в основном работаю в 2D (написание программ, Интернет, таблицы и так далее).
> Тут все просто. Около 70% транзисторов современных GPU используется исключительно для одной цели – ускоритель Direct3D. На сколько мне известно, с DirectX Linux платформа, мягко говоря, не дружит, вот они и не работают.
Ну, это уж совсем полная чушь. Для видеокарты не существует ни DirextX, ни OpenGL, а существуют низкоуровневые команды, которые она понимает. OpenGL или DirectX - это "прослойка" между программистов и видеокартой. И DirectX медленнее OpenGL в среднем по определению (в идеале разница совсем мала - не более несколько процентов) - ибо это прямое следствие организации архитектуры библиотек, DirectX стремится делать больше работы "для программиста", хотя по мне так это больше мешается, чем помогает. Но то уже дело вкуса.
Что касается DirectX под Linux'ом то я тоже в упор не вижу никаких проблем. Скорость работы DirectX под Linux'ом ненамного хуже, чем под Windows. Из-за кривых рук разработчиков DirectX может быть даже заметно быстрее (например, Postal 2 лучше запускать под DirectX, так как при этом кадров больше). Так что в Linux'е особых проблем с поддержкой DirectX нет, как и нет особых проблем с поддержкой собственно Windows API в целом (по-сути более 95% Windows программ прекрасно чувствуют себя под Linux'ом, однако полезных среди них очень мало, но то уже опять-таки дело вкуса). Если говорить о быстродействии в целом, то работа с памятью и процессором под Linux'ом быстрее, чем под Windows даже в Windows-приложениях, в чём легко убедиться запуская benchmark'и, активно использующие память и процессор, на одном и том же компьютере и под Linux'ом, и под Windows, затем сравнивая результат. Однако DIB и DirectX работают несколько медленее, чем под Windows, но для DIB это вообще не критично, а DirectX как правило медленее лишь на считанные проценты, что не играет роли. Мы сами подобных тестов не проводили, так как Windows не применяем, и, строго говоря, всё это нас совершенно не беспокоит - на практике важно только одно: работает хорошо или плохо, а коли хорошо, то какая вообще разница? Подсчётом процентов можно разве что заниматься от нечего делать. Но факт состоит в том, что видеокарта у нас работает совершенно полноценно. Например есть красивая демка Iconoclast - работает просто прекрасно. На старой видеокарте она работала некорректно (о чём сама предупреждала во время запуска, что наша карта, мол, не поддерживает многого из того, что она хочет), а на новой работает отлично со всеми эффектами рефракции, отражения и так далее с анизотропией 16x и антиалиасингом 16x. Эта демка применяет DirectX. Ну и игрушек на DirectX у нас тоже хватает, и проблем нет.
> Если есть запчасти со второго ПК – можно поэкспериментировать – поменять БП, видео карту, материнку.
Тут не запчасти с другого компьютера нужны, а видеокарта, причём новая, так как как работает старая мы знаем. БП и уж тем более материнская плата отношение иметь тут не могут. Вообще говоря строго в нормальном режиме работы помехи отсутствуют. Их можно получить только если на экране есть "сетка" из светлых и тёмных точек. Однако даже на нашей старой карте при этом были помехи, просто они были на порядок меньше. Я даже могу объяснить, почему это происходит, но вряд ли тут есть любители такого рода лекций.
В любом случае даже если карта работает идеально, а дисплей - ЭЛТ, то при отображении такого набора точек изображение вообще летит в полный разнос в любом случае, даже на самом профессиональном. Так что тут всё относительно. У нас есть и ЖК, и ЭЛТ дисплеи так что есть с чем сравнивать. Говоря иными словами, помехи есть везде, вопрос лишь в количестве. Ведь, скажем, ЖК монитор тоже наводит яркосно-цветовые помехи, как и ЭЛТ, особенно заметные на тёмном фоне, однако распределены они очень равномерно, а не хаотично, как у ЭЛТ. Однако если дисплей хороший, то они очень малозаметны (помехи самого глаза значительно больше). На профессиональном они будут настолько малы, что их вообще будет невозможно различить, что вовсе не значит, что помех нет. Всё-таки любое реальное оборудование аналоговое (даже если оно цифровое), и об этом следует помнить.
Лиссанро
*Кром*
Чтоошш, тогда и беспокоиться не о чем.
>Ну, это уж совсем полная чушь. Для видеокарты не существует ни DirextX, ни OpenGL, а существуют низкоуровневые команды, которые она понимает.
Тогда немного по другому спрошу. Вы тестировали потребление энергии платой во время простоя компа или же во время какого-нибудь современного бенч-марка видеосистемы? (3Dmark 01, 05, 06). GeForce 7600GS является одной из более дешевых вариаций карт 78хх, но, у многих производителей именно платы подобного класса хорошо предназначены для разгона, а в случае разгона энергопотребление еще сильнее увеличивается, тем более, иногда и на многие десятки процентов. Вот по этому и делают дополнительные разъемы питания.
Далее, как вы тестировали потребление? Ваттметром или же с помощью бесперебойника? Во втором случае вы бы вообще вряд ли получили хоть какую-то разницу, так как «измерительная» техника из ИБП просто смешная… по крайней мере я не встречал пока каких либо исключений из этого утверждения.
>DirectX стремится делать больше работы "для программиста", хотя по мне так это больше мешается, чем помогает. Но то уже дело вкуса.
По моим сведениям все несколько иначе. DirectX намного удобней для разработчика, но в силу многих факторов он медлительнее, и дальше эта тенденция только развивается. Чтобы увидеть это достаточно взглянуть на SDK от 7й и 9й версии и сравнить их. Но это ушш точно, дело вкуса.
>Что касается DirectX под Linux'ом то я тоже в упор не вижу никаких проблем. Скорость работы DirectX под Linux'ом ненамного хуже, чем под Windows.
=:\ а с небольшой примитивной программкой на DX7 у вас возникли какие-то непреодолимые проблемы =:\ называется, кажется «DragonDemo.exe»
>по-сути более 95% Windows программ прекрасно чувствуют себя под Linux'ом, однако полезных среди них очень мало, но то уже опять-таки дело вкуса
Ну не только вкуса, а скорее всего специализации. К примеру, почти все программы, которые мне приходится использовать, существуют только в исполнении для Windows или Mac. Исключение составляют программы для аудио\видео и Интернет. Конечно, можно их запустить под эмулятором, тут вопросов нет, но и утверждение того, что все ПО написанное для Windows имеет лучший аналог под другой ОС - я принять не могу. Для программиста, видимо по другому.
>В любом случае даже если карта работает идеально, а дисплей - ЭЛТ, то при отображении такого набора точек изображение вообще летит в полный разнос в любом случае
А что за изображение? Можно скриншот посмотреть? Я предполагаю, о чем ты, но точно знать не могу…
Поскольку после обновления драйверов видеокарты на новые (что мы уже давно сделали) проблема вообще исчезла (то есть уровень помех стал такой же, как и на был GeForce4 - то можно считать, что помехи отсутствуют), то действительно теперь не о чем беспокоится.
> Ваттметром или же с помощью бесперебойника? Во втором случае вы бы вообще вряд ли получили хоть какую-то разницу, так как «измерительная» техника из ИБП просто смешная…
Да вообще-то достаточно точная (погрешность измерения меньше 10 ватт). Так что разница в десятки ватт очень заметна. При желании можно замерить безконтактным ампер-метром (суть мультиметр с большими клещами), но у него погрешность будет 0.1 ампера то есть порядка 22 ватт. Более точные замеры требуют либо оборудование, которое стоит очень много тысяч долларов, либо замер в разрыве провода, но последнее неприемлимо, ибо возиться ради такого, чтоб замерить с точностью до десятых долей ватта потребление карты, нет никакого желания. Факт состоит в том, что потребляет она явно не столько, чтобы была реальная необходимость в дополнительном питании. Но нам в любом случае до этого нет дела, так как мощности БП хватает, карта работает, а на производителей мы влияние не имеем, а если б и имели, то это их проблемы, а не наши.
> По моим сведениям все несколько иначе. DirectX намного удобней для разработчика, но в силу многих факторов он медлительнее, и дальше эта тенденция только развивается. Чтобы увидеть это достаточно взглянуть на SDK от 7й и 9й версии и сравнить их. Но это ушш точно, дело вкуса.
У меня к DirectX отвращение воспиталось ещё задолго до того, как я узнал значение слова "Linux", то есть очень давно, и с тех пор это мнение только укрепилось. Дебильный API, идиотские имена функций, отсутствие документации, а та "документация", что есть (MSDN) - содержит пачки ляпов, недоговорок и ошибок с малым количеством примеров, неудобная работа с графикой на низком уровне - вот мои впечатления. Конечно, если юзать громоздкие средства ленивой "разработки", то это всё скрывается, но тогда уж точно глубоко без разницы, что ты юзаешь: OpenGL или DirectX. Так что пример некорректный у тебя. Я-то говорю именно о *программировании*.
Что касается медлительности DirectX - это факт, но эта "медлительность" не настолько велика по сравнению с OpenGL (считанные проценты, то есть разница теоритически незаметна). Как правило, причина медлительности лежит не в DirectX, а в кривых лапах разработчиков... Но с кривыми руками можно легко добиться, чтобы OpenGL был заметно медленее DirectX (как, например, имеет место быть в Postal 2, где нет смысла выбирать OpenGL даже в среде Linux'а). Так что главная причина в медлительности графики - не в том, DirectX или OpenGL приняется, а в том, что лапы кривые...
> =:\ а с небольшой примитивной программкой на DX7 у вас возникли какие-то непреодолимые проблемы =:\ называется, кажется «DragonDemo.exe»
Не возникло. Как ты помнишь, мы попробовали под Wine - не работает, попробовали под VMWare - запускается. Посмотрели, оценили ну и собственно всё. А вообще главная проблема той проги в том, что она применяет редкий API (а точнее редкие свойства некоторой его части), которые вряд ли найдёшь даже в каждой сотой DirectX игрушке. Ясное дело, что такое не может быть первичным приоритетом, да и даже обнаружить это сложно. Кто знает о проге, которая никому не известна, и о том, что, оказывается, она имеет какие-то проблемы?
В любом случае, с тех пор уже довольно много времени прошло, и на данный момент состояние поддержки DirectX вплоть до 9 включительно очень хорошее (поддержкой 10-го будут заниматься уже после выхода Wine 1.0, когда работа на всеми прочими DirectX будет окончательно подытожена - а это уже относительно скоро будет). На практике же (нашей) на данный момент работает ВСЕ игрушки, которые мы пробовали, а пробовали мы их не один десяток. То же и с обычными программами. То есть даже если где-то и находится нерабочая программа, то общей картины это ничуть не меняет. Тем более что Windows тоже далеко не все программы для Windows запускает правильно. Например, если программа имеет белёсый интерфейс невзирая на твою тему, а у тебя прописаны белые буквы, то получишь белые буквы на белом фоне. Под Linux'ом я могу для каждой программы прописывать разные темы, что невозможно под Windows, поэтому могу запускать и работать с такими программами. Однако на практике такой хлам обычно просто выкидывается и берётся другая программа, ибо зачем мне белёсая, если есть нормальная? Также под Windows (NT) не запускаются многие (но отнюдь не большая часть) игрушки для Windows (not-NT). Например, Worms 2, Sanitarium (Шизариум) и другие. Под Wine'ом они естественно работают без вопросов (по крайней мере нам исключений пока не попадалось, хотя у нас таких старых игрушек не так уж и много). Однако, если ты сидишь под Windows, ты просто возьмёшь другую игрушку, которая работает, и всё. Потому что работают большинство. Тоже и под Wine'ом. Я, например, знаю о игрушках, которые не работают под Wine'ом. Однако их процент ничтожен. То есть если я понаставил 20 игрушек, а двадцать первая не работает, то какое мне до этого дело? Максимум, bug report напишу. Или не напишу, а сам исправлю (если уж действительно игрушка мне интересна; как, скажем, пользователь Windows XP начнёт ставить Windows 98, коли ему припрёт играться именно в *эту* игрушку, которая не работает в XP даже в режиме с совместимости, но работает в 98 - но на практике скорее просто возьмёт следующую). Но в любом случае того факта, что более 95% Windows программ работают без вопросов под Linux'ом не изменится (разве только что в лучшую сторону), включая в том числе и такие громоздкие пакеты как Photoshop, Lightwave, Matlab. Пример: 3ds max 4 и выше не работает под Wine'ом из-за своей "защиты". Это не исправлено и по сей день, так как никому по-настоящему не нужно (все либо юзают другие редакторы, либо, если совсем нужно, запускают по-другому) - так, на сайте CodeWeavers никто не положил даже доллара за то, чтобы поддержка 3ds max была сделана, зато кладутся деньги на многие другие профессиональные программы, и их поддержка вводится в Wine и CrossOver (по-сути, это организованный косвенный наём программистов). Я, например, запускаю 3ds max с DirectX в VMWare. При этом он спокойно располагается на одном из рабочих столов (как и положено), я могу с ним без проблем работать и так далее. Да, под VMWare он работает несколько медленее, но мне нет особой разницы, отрендериться ли каритна за минуту, или за минуту 30 секунд. Под Wine всё конечно бы работало быстрее, причём даже быстрее, чем под Windows (что было проверено на 3ds max 3 стороними лицами, так как мы такими "benchmark'ами" не занимаемся). Вообще, это очень характерно, что если программа активно юзает память и проц, то под Linux'ом под Wine'ом она работает несколько быстрее (однако разница опять-таки мериться процентами, то есть незаметна "на глаз") - причина на то проста: в ядре Linux'а работа с памятью и процессор реализованы очень грамотно.
> Ну не только вкуса, а скорее всего специализации. К примеру, почти все программы, которые мне приходится использовать, существуют только в исполнении для Windows или Mac.
Скорее ты просто не знаешь об альтернативах. Но в любом случае я в таких вещах проблемы не вижу. Так как если применение нелегальных программ считается приемлимым, то тогда для тебя почти все программы бесплатны. А раз так, то какая разница? Например, у нас в дистрибутиве нет словаря для перевода английского на русский (это нужно брату). Поэтому мы скачали словарь для Windows, он автоматически запускается, когда заходишь в KDE, его иконка висит в трее вместе со всеми прочими Linux и Windows-программами, которые туда выводят значок, переводит выделенный текст по горячей клавише - короче работает идеально, полностью интегрируясь в среду.
Вообще, мы стараемся ипользовать Linux'овые программы всегда, где это возможно, так как под Linux'ом часто всё намного удобнее сделано (не потому, что оно "под Linux", а именно потому что сделано лучше). Однако в целом обычно это глубоко без разницы, под Linux программа, или под Windows... Работает-то и то и другое. Разница только в том, что для Windows нужно скачивать из Сети, затем ещё взламывать (может отнять много времени, если кто-то не взламал за нас), а для Linux'а уже всё есть в дистрибутиве (под 20000 программ на 3 DVD, хотя иногда бывает так, что нужное приходится качать из Сети, но эти случаи очень нечасты) и качать/ломать ничего не нужно, за очень редкими исключениями (например, VMWare).
А вообще, всё это уже полный оффтопик. Тут тема было о видеокарте только, и эта тема полностью закрылась после обновления NVidia драйвера, хоть мы об этом тут и не писали. Так что если захочешь что-то ответить - пиши в U-Mail, чтобы не оффтопить дальше на дневнике, тем более что и оффтопить больше не о чем, так как все темы закрыты. Однако в любом случае даже в U-Mail ты сначала по делу отпишись, мы ведь всё ещё ждём.