https://www.opennet.me/openforum/vsluhforumID3/108408.html Компания Google объявила (http://blog.chromium.org/2016/06/universal-rendering-with-swiftshader.html) о полном открытии исходных текстов библиотеки SwiftShader (https://swiftshader.googlesource.com/SwiftShader), в рамках которой подготовлена система высокопроизводительного рендеринга, предоставляющая реализацию графических API OpenGL ES 1.1/2.0/3.0 и Direct3D 9, выполняемую на CPU. Код открыт (https://swiftshader.googlesource.com/SwiftShader) под лицензией Apache 2.0. <br><br><br>Целью проекта является предоставление возможности отображения расширенной 3D-графики независимо от используемого оборудования и графических драйверов. SwiftShader уже задействован Chrome для организации работы WebGL на системах без современных GPU или для обхода проблем в графических драйверах, а также предложен в инструментах для разработчиков Android. SwiftShader также может применяться на серверных системах без GPU для организации рендеринга и работы графических приложений в облачных окружениях.<br><br><br><br><br><br>Для достижения должного уровня https://www.opennet.me/openforum/vsluhforumID3/108408.html#28 Fri, 28 Feb 2020 16:57:29 GMT А Вы попробуйте, произвести "расшифровку" (математическое преобразование) бинарных данных, глядишь структура и появится! ;)<br> https://www.opennet.me/openforum/vsluhforumID3/108408.html#27 Mon, 11 Jul 2016 22:24:56 GMT &gt; Да, но генерация и парсинг текста более подвержен ошибкам и сюрпризам, чем обработка бинарных данных.<br><br>Похоже путаешь слова "структурированный" и "бинарный"<br>Если неизвестна структура, то обработка бинарных данных вообще невозможна.<br> https://www.opennet.me/openforum/vsluhforumID3/108408.html#26 Sat, 02 Jul 2016 17:43:29 GMT * "встраиваемый язык Reactor" + ets - ууу шлакище, и забудьте про доп.оптимизацию компилятором<br>* и потому же даже не глядя - понятно: ценность кода 0%<br>* гугл "открыл" - не значит убрал проприетарность, лень смотреть - но, Apach2.0 врядли = BSD лицензия<br>* гугл "открыл" т.к.Dx9 - подустарел... видать надеются на то что их, fucked Adroid гугл, коды - найдутся лошки и рабы за бесплатно допиливать его им... <br> https://www.opennet.me/openforum/vsluhforumID3/108408.html#25 Fri, 01 Jul 2016 09:52:24 GMT &gt; сть мнение, что даже качественные проекты, если они не умеют внятно <br>&gt; комбинироваться/управляться пользователем:<br>&gt; 1) не дают возможности решить кучу задач, которые легко решаются комбинированием<br><br>дело в том, что проект, который "не позволяет решать кучу задач комбинированием", от личется от того, который "позволяет", тем, что позволяет разрабам грести лопатой бабло за встраивание дополнительных "вариантов использования". Мало того, на курсах, где читают UML, об этом прямо и говорят -- при любой возможности вместо того и того, следует использовать "варианты использования" -- это гарантированно позволяет взять с длинного заказчика бабала кратно больше.<br><br><br><br><br><br> https://www.opennet.me/openforum/vsluhforumID3/108408.html#24 Thu, 30 Jun 2016 20:41:14 GMT &gt; на нынешней же аппаратуре?!..<br><br>Для вычислительных мощностей можно найти более полезное применение, чем нескончаемые пребразования из представлений, специфичных для конкретных программ, в текст и обратно (внутренние структуры программы 1 -&gt; текст -&gt; в.с.п. 2 -&gt; текст -&gt; в.с.п. 3 -&gt; текст -&gt; ...). Текстовое представление универсально в плане возможности представления чего угодно, но крайне неэффективно для машинной обработки.<br><br>&gt; ошибки/неожиданности могут быть всегда и везде<br><br>Да, но генерация и парсинг текста более подвержен ошибкам и сюрпризам, чем обработка бинарных данных. Например, 32-битное целое в бинарном виде -- всегда 4 байта, которые достаточно прочитать из памяти и сразу использовать без всяких заморочек с преобразованиями (в обсуждаемом контексте набора локально выполняемых программ порядок байт значения не имеет), в текстовом представлении появляются форматы JSON/XML/YAML/CSV/..., системы счисления и плоды фантазии разработчика конкретной программы, "участвующей" в цепочке обработки данных. П https://www.opennet.me/openforum/vsluhforumID3/108408.html#22 Thu, 30 Jun 2016 14:26:27 GMT Позвольте с Вами отнюдь!..<br>&gt; ...<br>&gt; С другой стороны - тот unix way, который обычно поминают (текстовые команды, <br>&gt; пайпы и нетипизированные потоки): <br>&gt; 1) адски неэффективен на нынешних объёмах данных из-за кучи IPC <br><br>да ладно! на нынешней же аппаратуре?!..<br><br>&gt; 2) рискован в плане непредсказуемых эффектов, так как приходится парсить кучу довольно <br>&gt; непредсказуемого текста<br><br>как-то не в тему - ошибки/неожиданности могут быть всегда и везде, - как монолитность может помочь - не понимаю! Но наоборот - в мелкой и простой задаче/действии легче и надежнее решение.<br><br>&gt; 3) имеет хреновый для запоминания/понимания интерфейс - сейчас количество ключей запросто за сотню зашкаливает <br><br>Опять же - как правило это наоборот, для монстров, а не unix way! Если ты делаешь одну операцию, то тебе не надо 100500 опций.<br><br>&gt; 4) проблематичен при двустороннем обмене - например, я не представляю, как сказать <br>&gt; find на основе анализа отданного им файла, что все следующие такого <br>&gt; же типа надо пропустить <br><br>И опять недопо https://www.opennet.me/openforum/vsluhforumID3/108408.html#21 Thu, 30 Jun 2016 13:55:02 GMT &gt; А netbsd используется с иксами?<br><br>А netbsd используется? [FIXED]<br> https://www.opennet.me/openforum/vsluhforumID3/108408.html#20 Thu, 30 Jun 2016 10:36:15 GMT &gt; А компьютер - это UNIX-way? <br><br>Вы не поверите, но обычно таки устройства для вывода изображения, ввода/хранения данных, подключения к сети и т.д. идут раздельно и вполне спокойно (пока) заменяются/подключаются &#8212; ну там более быстрая графика плюс геймпад для игрушек, проф. звуковая карта и прочее для музыкантов-звуковиков, мониторы с клавиатурами на вкус и цвет для всех желающих.<br><br>Т.е., путем подбора/замены отдельных компонентов компютера можно очень неплохо "заточить" его под какую-то задачу. <br><br>А вот наоборот обычно таки не катит &#8212; на "мобилке" и бухучет вести неудобно, и с музыкой особо не поработаешь и в стрелялку-что-то-там не поиграешь и даже на опеннете троллить не ахти &#8230;<br> https://www.opennet.me/openforum/vsluhforumID3/108408.html#19 Thu, 30 Jun 2016 09:04:13 GMT Есть мнение, что даже качественные проекты, если они не умеют внятно комбинироваться/управляться пользователем:<br>1) не дают возможности решить кучу задач, которые легко решаются комбинированием<br>2) вместо сравнительно простой ментальной модели заставляет пользователя запоминать вагон отдельных вариантов действий, которые для unix way легко выводятся при нужде<br>3) неудобны для автоматизации<br><br>Другими словами, для power user это неудобно.<br><br>С другой стороны - тот unix way, который обычно поминают (текстовые команды, пайпы и нетипизированные потоки):<br>1) адски неэффективен на нынешних объёмах данных из-за кучи IPC<br>2) рискован в плане непредсказуемых эффектов, так как приходится парсить кучу довольно непредсказуемого текста<br>3) имеет хреновый для запоминания/понимания интерфейс - сейчас количество ключей запросто за сотню зашкаливает<br>4) проблематичен при двустороннем обмене - например, я не представляю, как сказать find на основе анализа отданного им файла, что все следующие такого же типа надо пропустить<br>5)