Хорошая новость. Ибо Панорама для меня пока не юзабельна: в ней оверлей не работает и чинить никто не собирается.

Да это очень своевременно. Так как драйвера сейчас не поспевают за софтом. (Firefox, Open office и.т.д) есть некоторая тормознутость, правда сказать Panorama VESA вытягивает, но все равно не на должном уровне.

Будем надеется на обновления этих продуктов и качественную работу видео...

А разве SNAP не стал OpenSource на какое то время?

И сейчас, судя по новости, исходники перешли снова в разряд Closed.

Или моя память мне злостно с кем-то изменяет?

Igor Vaskov

Вроде как да были открытые, но легче от этого не стало так и не чего кроме Panorama VESA не появилось.

Может так все-таки лучше будет??

Да я вообще уверен, что разработка при закрытых исходниках гораздо более продуктивна. Ибо никому не хочется вкладывать деньги в то, чем все могут пользоваться потом на халяву. Беда в том, что средств на разработчиков и самих разработчиков не наблюдается. Хотя теперь, я думаю, хозяин приложит усилия для продолжения разработки продукта.

CraigM: So what you all think of mensys getting the SNAP drivers?

Grimus: CraigM: Great, but only a first step. Let's see if they get the right resources (programmers, e.g., Michal Necasek) and strategic decisions that benefit the community, e.g. focus on limited number of chipsets, but full feature set. I am afraid the right business decision will rather be rock solid basics on a maximum number of chipsets...

At least they have to solve SMP compatibility for SNAP. This is needed also by business costumers

CraigM: I agree and actually don't mind that...makes my purchasing a great video card easier

Нужно делать на максимальное количество чипов, то -есть постепенно добавлять если не возможно сделать сразу..

Одна из лучших новостей за последнее время.

УРРРААААА!!! А то на Панораму, я смотрю, разработчики забили, рефреш менять даже в планах нету...

Hendrik: Does this mean that there is a chance for support of newer gpu chipsets ?

Roderick Klein (Mensys):

Compared to 2 or 3 years ago its becoming easier as more and more companies are merging that manufactor GPU chipsets.

But as I have written before in forums. Supporting GPU in a native fashion is not the best solution. We don't have all the man power.Some people volunteered but I still

have the impression going with a VESA driver is better.

Next to that with **proper** setup of MTRR registers and a generic wide screen enabler we should have enough speed and support for non standard resolutions.

We (Mensys) do not suspect the VESA interface will go away that quickly. Other people speculate it might go away VESA support, but I have not yet seen any hard technical evidence for that. If anybody has that envidence then

please let me know.

Roderick Klein:

This is part of an email with some additional info that I posted about a month ago to the eComStation developer mailing:

"If you look closely at my Warpstock presentations, you can see that Panorama has to be updated to setup MTRR registers correctly on modern CPU's. There is a lot of BS going around about Panorama. The reason it's slow on some machines is because the MTRR registers are not set properly. SNAP in some cases also does it wrong. This can give up to a 100 fold performance difference (we measured that with Sysbench on one system with correctly and incorrectly set MTRR registers).

We also have a developer in the US that is working on a wide screen enabler. The goal is to support in VESA mode, resolutions that the VESA BIOS does not provide normally.

There are no human resources to write native video drivers currently. Scitech at the time had situations where a video chipset would be native supported on one, but not another system, even if it was certified. Hence the reason why VESA support with proper MTRR value's and the wide screen enabler will get much higher priority, then native chipset support.

There is one thing however that people need to understand about SNAP. SNAP is not the holy grail. SNAP, just like Panorama, relies on screen01.sys and other parts of the GRADD video subsystem.. Also some of the lower video components need to be updated. We already have access to a rewritten version of SCREEN01.SYS in C but that needs further work. BHSVGA.DLL and VSVGA.SYS will require some maintance as well. This will also require man hours.

Next to that SNAP seems to have problems on some SMP systems. SNAP does not work properly with suspend/resume of ACPI. The VESA code of Panorama needs to be put into SNAP and the screenbuffer code of Panorama needs to be fixed to support DIVE correctly.

So native chipsets support is not ruled out but currently none are planned as first a lot of work needs to be done on SNAP itself and the underlying GRADD code."

Ясно, но хоть так - уже не плохо если до конца будет доведен VESA GRADD драйвер..

Не думаю, что менсис много заплатил за snap, поэтому много не потеряет ;) Но ветвь то тупиковая, как сам менсис и понимает.

нискока не опоздали выкупить

ну лет 6 думали панорамой обойтись...

тут вот на (пример) nv gt430 _видюхой_, не загружая цпу, hd давно смотрим

и когда это снап с панорамой смогут?

на дворе 2011, когда уже двд формат помер, везде hd мониторы-телевизоры

а про тупик с видюхиными драйверами я толдычу без счету лет

SNAP был довольно хорошим и оверлей появился можно было довести до нормального состояния.

Поэтому я думаю что в этом направлении как раз и будут сделаны усилия. Ну не заставишь производителей писать для разных ос драйвера не хотят они. Мне так кажется это очень перспективное направление, так как подрузомевает уневерсальность для многих карт и если-бы производители немного посмотрели-бы в эту сторну то они очень серъезно выиграли. Я имеею ввиду железо, которое работало-бы по каким-то уневерсальным инструкциям...

Новость интересная.

Но с технической точки зрения, почему под eCS так мало нормальных реализаций opensource видеодрайверов? Насколько сложно портировать, к примеру, открытые Ati драйвера из X.org [url] или Nouveau драйвера [url] ? Дело просто в малом количестве разработчиков драйверов -- или в том, что драйвера в текущей архитектуре разрабатывать сложнее чем это должно быть?

Как пример: Nouveau было портировано в AROS [url] .

AROS -- Это римейк AMiGA OS. Драйвера устроены просто. Судя по тому, что Nouveau драйвера появились для AROS, Nouveau архитектуру драйверов портировать на другую ОС должно быть не очень сложно.

Также, для NVidia есть простая прозрачная реализация драйверов в Haiku и в Plan9. Драйвера для Haiku были написаны почти в одиночку Rudolf Cornelissen, см. https://www.haiku-os.org/legacy-docs/writing-video-card-drivers -- хорошее описание устройства видеодрайвера вообще и реализации в Haiku в частности. (То есть, и один в поле воин, при правильном подходе и упорстве.)

По текущему состоянию, имеем в Haiku в SVN trunk довольно простую в смысле API реализацию нативных драйверов с 2d ускорением, правда чипсетов видеокарт поддерживается пока в целом меньше, чем в Nouveau в Линухе. Для 3d ускорения есть зачатки, но всё упирается в более современный порт MESA с Gallium(форк Mesa в Haiku отстал от Mesa в Linux). Также имеем VESA драйвер "из коробки", с MTRR и прочим.

В Plan9, см. в "дистрибутиве Plan9" -- plan9front: [url] смотреть надо [url] -- это Generic VESA драйвер, и NVIDIA драйвер [url] . Описание, как устроены драйвера в Plan9 [url]

То есть, по текущему состоянию в Plan9 есть nvidia драйвер, бекпортированный из nv драйвера для X.org, который поддерживает 2d ускорение. Чипсетов поддерживается не очень много, ИМХО, меньше, чем в Haiku.

Эти драйвера интересны тем, что как и в Haiku -- реализация самого драйвера простая и прозрачная, значит, их портировать должно быть не сложно. Проще писать, проще отлаживать, проще портировать и поддерживать.

Итого, вопрос: Насколько сложно портировать в eCS драйвера из (по нарастанию "сложности"): Plan9, Haiku, AROS Nouveau, Linux Nouveau ???

Где можно почитать про устройство видеодрайвера в eCS, какая архитектура драйверов самая последняя и т.п. в целом -- насколько просто/сложно портировать драйвера из этих ОС в eCS??? то есть, насколько просто архитектуру этих драйверов в других ОС отобразить на архитектуру драйверов в eCS?

Другой вопрос. Смысл и польза SNAP как продукта.

Мне нравится идея и архитектура SNAP, но по-моему, Nouveau его частично повторяет (из таких "более других" кирпичиков, как ядро:KMS/DRM, Mesa/Gallium3d/llvm, часть X.org).

На примере общего между AROS Nouveau/Linux Nouevau -- драйвера в Linux устроены однотипно из трёх частей [url] :

Nouveau is made of 3 components: DDX (2D driver), DRI (3D driver) and DRM (kernel component).

1. часть ядра: KMS ("Kernel Mode Switching") -- для установки MTRR, видеорежимов.

2. Часть ядра: DRM

3. 2d и 3d ускорение (DDX и DRI+ Mesa/Gallium3d).

Про описание Mesa/Gallium3d:

[url]

[url]

[url]

смысл этой штуки -- state trackers:

[url]

вытащить платформенно-зависимую (nvidia,ati,intel) часть в отдельный модуль.

модуль собирается llvm компилятором, так что тут нужна родная llvm с соотв. бекендом (??? или можно обойтись кросскомпиляцией???)

на примере AROS/Nouveau и Linux/Nouveau, фактически видим, что Nouaveu требует от ОС реализации этих трёх модулей, в том или ином виде. Пример AROS/Nouveau показывает, насколько минималистичными такие модули могут быть. Но всё-таки какие-то изменения в ядре могут потребоваться.

Вопрос, Насколько сложно такие изменения провести в ядре eCS.

----

Теперь сравниваем такую архитектуру со SNAP. Похожие части: зависимые от архитектуры GPU модули/зависимые от ОС модули, модульность как таковая, в перспективе мобильность -- сборка драйвера другим компилятором (а не llvm/clang).

Вопрос, а в чём основная ценность по сравнению с такой архитектурой Nouveau/Gallium3d/Mesa/llvm

-- как продукта архитектуры SNAP или основанных на его базе драйверов???

===

Итого (моё ИМХО):

1. Очевидно, что SNAP нужно обновить поддержкой новых современных чипсетов видеокарт. Пример готовой, работающей реализации такой поддержки можно посмотреть в AROS/Nouveau,Linux/Nouveau (перспективнее, но сложнее) или Haiku, Plan9 (проще, минимальный нативный драйвер). Есть ли какие-либо проблемы с портированием драйверов по BSD лицензии, например?

2. Возможно, архитектуру SNAP нужно обновить по образу связки Nouveau/Mesa/Gallium3d. Либо проще наоборот, привести Nouveau архитектуру к SNAP-подобному виду?? В идеале должно получиться лучшее из двух.

3. Возможно, в ядре нужно обновить модули по образу KMS/DRM в Linux и в GUI PM по образу из X.org DDX/DRI. ???(опять таки, в идеале все такие изменения должна абстрагировать "архитектура драйверов").

4. Неясно в целом, какой подход проще: доработать SNAP или портировать нативные драйвера по образу Nouveau/Mesa/Gallium3d. AKA: "В чём ценность как продукта архитектуры SNAP или альтернативной".

5. IMHO, должно быть как минимум 2 альтернативных реализации драйверов видеокарт для eCS, opensource и закрытых. Одна для экспериментов с архитектурой драйверов/подсистем и массовой поддержки чипсетов GPU, портированной из других ОС и другая -- стабильная, с "правильной" архитектурой (как в SNAP) когда понятен подход в архитектуре (и трудоёмкости) разработки видеодрайверов. Также можно разнести их по разным лицензиям (закрытые/BSD vs. GPL).