Да не аппаратная эта разгонялка, вы что. Это просто аппаратный фронт энд для софтварной разгонялки. Как-то к этой штуковине имеются драйвера, которые управляют частотами видеокарты посредством обращений к ForceWare драйверу. Только и всего.
Это все конечно хорошо, но лично каждому из пользователей мак ос на PC это лишь принесет некое эстетическое удовлетворение, потому что Mac OS не станет в раз совместима с огромным количеством железа, которое выпущенно на рынок комплектующих.
Хм хм, пусть сначала найдется тот, кто разработает для макоси достойную альтернативу, а то пока Songbird в преальфа состоянии, и Cog, который сложно назвать плеером )
Простите, вот давайте оставим моральный аспект в сторонке. Apple — многомилионная корпорация, которая не разрешает свой программный продукт, устанавливать на аппаратное обеспечение 3-их фирм. Psystar — просто группка лиц, которая занималась IT-консалтингом, а теперь за счет знаний и нароботок комьюнити (в том числе и моих, хотя GPL не накладывает ограничения на коммерческое использование) решила заработать и пропиарится. С этим разобрались, как видите все при своих интересах и отнюдь не белые и пушистые.
А теперь пример. Вы покупаете mp3 плеер фирмы XXXXX. Это аппаратное обеспечение, конечно же он работает под управлением специально разработаной firmware (прошивки). Также фирма ХХХХХ регулярно предлагает вам обновления прошивок за совершенно символическую сумму. Естественно, труд программистов, который был вложен — гораздо больше, нежели сумма прошивки. Таким образом фирма ХХХХХ с вашего согласия продает вам саппорт.
А теперь как думаете, легально ли купить обновления прошивки и установить его на плеер другой компании? Фактически вы не покупая продукт у компании, пытаетесь купить у нее саппорт. Но компания не ориентирована на продажу саппорта, она ориентированна на продажу mp3 плееров…
Считайте, что мак — это mp3 плеер, а Mac OS X — прошивка для него.
Ну обсуждали ведь уже не один раз. На ноуты наценка на 20-30%, считайте это платой за Mac OS и уникальный юзер экспириентс. А на десктопы цены высокие из-за использования мобильный комплектующих в iMac, Mac Mini и серверных в Mac Pro.
«многим нравится её идея и они открыты для неё, но они не хотят тратить необоснованно высокую цену за самое обычное железо.» однако. Google translate? Поправьте пожалуйста. И немного верстку, а то будут минусовать.
Субноутбуки — пожалуй тут ARM будет смотреться не очень кстати, а вот UMPC и мобильные телефоны/смартфоны — другое дело. Посмотрите на Maemo, Android, iPhone. В эти платформы в итоге ARM based (всмысле Android успешно работает на ARM based SoC). И тут пожалуй есть где разогнаться :)
Вот что очень не помешало бы, так это добавить в программу запоминание языка ввода для каждого поля ввода, или хотя бы окна, а то очень напрягает текущая ситуация. Попробую покопать в данном направлении.
Во-первых Darwin, а не Denver. Mac OS X — это не только Darwin, а еще куча настроек, CoreFoundation, CoreGraphics, CoreAudio, AppKit и т.д.
Вы вкурсе о Mac Pro? У меня знакомый артдиректор одной московской фотостудии использует Mac Pro 2 4 ядерных Xeon + 10 гб FB-DIMM ОЗУ, GF8800, и ему хватает этой производительности с головой. 42 гб данный в фотошопе за два дня — это нормально.
Так что маки бывают тоже очень мощными, и не одними мак буками и аймаками единны. Производительность нужна на работе, и совсем не многим она нужна дома. А игры… Человек который купит мак, для игр купит консоль.
Они виснут и по разным мелочам. Даже во время того, спотлайт индексирует файлы. Крашей родных приложений у меня было действительно достаточно мало, но подвисания случаются регулярно. Товарищ прав, идеального ничего нет.
Вы уж извините, но ОС, как и любой другой софт с огромными вложенными в него средствами не оценивается за 10 минут. В Mac OS X тоже совсем не все привычно, только спустя время привыкаешь и понимаешь, что да, так гораздо лучше, нежели то, чем я раньше пользовался. Но на это нужно время и отнюдь не 10 минут.
Я о чем. О том, что стоит потрудится ломать свои привычки.
> И, например, если в качестве места назначения указана видеопамять, то успешно можно загадить экран какими-нибудь кракозяблами.
Да, можно ошибится с адресами и запортить содержимое памяти по случайному адресу, но если честно я не знаю, как можно было бы копировать участок физической памяти с одного адреса, на другой. Я так понимаю для этого нужен какой-нибудь центральный DMA контроллер или аппаратный IO MMU, но x86 этого нет, вернее в PCI нету централизированного контроллера, вместо этого bus mastering и придумали ведь ;)
> Лучше написать: на физическое адресное пространство. Потому что память никуда не девается, просто host-контроллер перенаправляет запросы на чтение/запись по определённым адресам на шину PCI.
Согласен, изменил формулировку. Правда память от этого свободной не становится, и int 15h сообщает системе, что память занята. Кстати надо будет в этом месте дополнить статью о memory remap.
> На скорость доступа, кстати, это никак не влияет.
Это только так кажется. На самом деле на IO порты обязательно вешается в SMI хендлере IO Trap, для самых разных нужд, как-то эмулирование для приложений PS/2 мыши и клавиатуры, когда вместо них — USB. Перенаправлением запросов в этом случае занимается SMI хендлер. Так что тут тоже есть определенный оверхед, хоть и небольшой :)
> Сначала драйвер(кстати, чей дравер? ОС?) выделяет память под DMA буферы.
Драйвер устройства, я его тут называл драйвером ОС, чтобы никто не запутался.
> Но кто следит за overhead'ами? Если буферов оказывается недостаточно, кем, как и когда данная ситуация распознаётся и как/на каком этапе решается?
Зависит от ситуации. Если у нас к примеру есть драйвер сетевой карты (я именно с ними имел достаточно много дела), то мы можем говорить о двух случаях:
1. overrun при отсылке пакета.
2. overrun при приеме.
Если имеет место первый случай, то очевидно, что overrun обнаруживает драйвер устройства в одной из своих процедур (например в Mac OS X, всмысле IOKit, это метод IOEthernetController:: outputPacket). overrun происходит из-за того, что устройство по какой-либо причине не успевает отправлять пакеты. Решение в данном случае, вернуть в процедуре драйвера код ошибки по типу output queue stalled. ОС просто перешлет этот пакет посже. Ну и если такая ситуация будет повторятся подряд на протяжении какого-либо времени, например контроллер повис, то значит нужно в драйвере это отслеживать и вовремя ресетнуть контроллер.
Если второй, то overrun обнаруживает сетевой контроллер. Он посылает прерывание и в регистре статуса прерываний выставляет какой-нибудь флажок, типа input queue overrun. Это сигнал драйверу, что нужно что-то делать. Как вариант, дропнуть старые пакеты в очереди и выставить в дескрипторе флажок, что буфер свободен, или же провести ресет контроллера.
> Каков обычно размер этого односвязаного списка DMA-буферов?
Зависит от конкретной железки. 64, 256 может быть. Может быть и больше.
> Это ведь нерационально каждый раз просматривать его.
Просмотреть 256 дескрипторов и проверить наличие установленного флага, что буфер был получен и его необходимо переслать на уровень выше — не такая уж и тяжелая задача. Есть разные методики. Например сетевые контроллеры от Realtek раньше просто писали подряд в каждый буфер в этом кольцевом списке дескрипторов, и после заполнения одного буфера давали прерывание. Посему драйвер мог хранить индекс текущего буфера и легко инкрементировать его после каждого прерывания.
> Причём я так понимаю под «пересылает данные из буфера» имеется ввиду копирование этих данных?
Верно, в случае сетевых драйверов, создается сетевой пакет (в Mac OS X — это mbuf, в линуксе — skb) и данные из буфера копируются в этот пакет.
А теперь пример. Вы покупаете mp3 плеер фирмы XXXXX. Это аппаратное обеспечение, конечно же он работает под управлением специально разработаной firmware (прошивки). Также фирма ХХХХХ регулярно предлагает вам обновления прошивок за совершенно символическую сумму. Естественно, труд программистов, который был вложен — гораздо больше, нежели сумма прошивки. Таким образом фирма ХХХХХ с вашего согласия продает вам саппорт.
А теперь как думаете, легально ли купить обновления прошивки и установить его на плеер другой компании? Фактически вы не покупая продукт у компании, пытаетесь купить у нее саппорт. Но компания не ориентирована на продажу саппорта, она ориентированна на продажу mp3 плееров…
Считайте, что мак — это mp3 плеер, а Mac OS X — прошивка для него.
Вы вкурсе о Mac Pro? У меня знакомый артдиректор одной московской фотостудии использует Mac Pro 2 4 ядерных Xeon + 10 гб FB-DIMM ОЗУ, GF8800, и ему хватает этой производительности с головой. 42 гб данный в фотошопе за два дня — это нормально.
Так что маки бывают тоже очень мощными, и не одними мак буками и аймаками единны. Производительность нужна на работе, и совсем не многим она нужна дома. А игры… Человек который купит мак, для игр купит консоль.
Я о чем. О том, что стоит потрудится ломать свои привычки.
Да, можно ошибится с адресами и запортить содержимое памяти по случайному адресу, но если честно я не знаю, как можно было бы копировать участок физической памяти с одного адреса, на другой. Я так понимаю для этого нужен какой-нибудь центральный DMA контроллер или аппаратный IO MMU, но x86 этого нет, вернее в PCI нету централизированного контроллера, вместо этого bus mastering и придумали ведь ;)
> Лучше написать: на физическое адресное пространство. Потому что память никуда не девается, просто host-контроллер перенаправляет запросы на чтение/запись по определённым адресам на шину PCI.
Согласен, изменил формулировку. Правда память от этого свободной не становится, и int 15h сообщает системе, что память занята. Кстати надо будет в этом месте дополнить статью о memory remap.
> На скорость доступа, кстати, это никак не влияет.
Это только так кажется. На самом деле на IO порты обязательно вешается в SMI хендлере IO Trap, для самых разных нужд, как-то эмулирование для приложений PS/2 мыши и клавиатуры, когда вместо них — USB. Перенаправлением запросов в этом случае занимается SMI хендлер. Так что тут тоже есть определенный оверхед, хоть и небольшой :)
> Сначала драйвер(кстати, чей дравер? ОС?) выделяет память под DMA буферы.
Драйвер устройства, я его тут называл драйвером ОС, чтобы никто не запутался.
> Но кто следит за overhead'ами? Если буферов оказывается недостаточно, кем, как и когда данная ситуация распознаётся и как/на каком этапе решается?
Зависит от ситуации. Если у нас к примеру есть драйвер сетевой карты (я именно с ними имел достаточно много дела), то мы можем говорить о двух случаях:
1. overrun при отсылке пакета.
2. overrun при приеме.
Если имеет место первый случай, то очевидно, что overrun обнаруживает драйвер устройства в одной из своих процедур (например в Mac OS X, всмысле IOKit, это метод IOEthernetController:: outputPacket). overrun происходит из-за того, что устройство по какой-либо причине не успевает отправлять пакеты. Решение в данном случае, вернуть в процедуре драйвера код ошибки по типу output queue stalled. ОС просто перешлет этот пакет посже. Ну и если такая ситуация будет повторятся подряд на протяжении какого-либо времени, например контроллер повис, то значит нужно в драйвере это отслеживать и вовремя ресетнуть контроллер.
Если второй, то overrun обнаруживает сетевой контроллер. Он посылает прерывание и в регистре статуса прерываний выставляет какой-нибудь флажок, типа input queue overrun. Это сигнал драйверу, что нужно что-то делать. Как вариант, дропнуть старые пакеты в очереди и выставить в дескрипторе флажок, что буфер свободен, или же провести ресет контроллера.
> Каков обычно размер этого односвязаного списка DMA-буферов?
Зависит от конкретной железки. 64, 256 может быть. Может быть и больше.
> Это ведь нерационально каждый раз просматривать его.
Просмотреть 256 дескрипторов и проверить наличие установленного флага, что буфер был получен и его необходимо переслать на уровень выше — не такая уж и тяжелая задача. Есть разные методики. Например сетевые контроллеры от Realtek раньше просто писали подряд в каждый буфер в этом кольцевом списке дескрипторов, и после заполнения одного буфера давали прерывание. Посему драйвер мог хранить индекс текущего буфера и легко инкрементировать его после каждого прерывания.
> Причём я так понимаю под «пересылает данные из буфера» имеется ввиду копирование этих данных?
Верно, в случае сетевых драйверов, создается сетевой пакет (в Mac OS X — это mbuf, в линуксе — skb) и данные из буфера копируются в этот пакет.