Осталось покрасить, помыть и зарелизить

Дано: Qt5 рулит, но есть проблемы с ним на андроеде: херово он собирается, глючит и занимает 35 метров. Challenge: уменьшить Qt, убрав оттуда лишнее, поправив глюки, запилить фичи вроде gl4 в quick2

Я нашел такие подводные камни

1)требуется -DQT_OPENGL_FORCE_SHADER_DEFINES иначе матерятся компиляторы шейдеров на андроиде(fly 256, еще планшет какой-то), эмуляторе(intel, fglrx, были жалобы на нвидию).

2)qtmultimedia jar.pri: API_VERSION = $$ANDROID_NDK_PLATFORM

3)в NDK надо подкостыливать ссылками каталог platforms: ln -s android-9 10 && ln -s android-14 15

4)в SDK/build-tools ln -s android-4.2.2 17.0.0 (иначе не работает make clean)

5)Патчи

вкусный патч для тех, кто хочет GL 3 или 4 в окне QtQuick2. Заодно помогает от fglrx

qtbase/src/gui/kernel/qtsurfaceformat.*: в класс QSurfaceFormat добавить

/*qsurfaceformat.h*/
public:  static const QSurfaceFormat& getDefault(){return m_default;}
void setDefault(){m_default=*this;}
private: static QSurfaceFormat m_default;
/*qsurfaceformat.cpp*/
QSurfaceFormat QSurfaceFormat::m_default;

-QSurfaceFormat format;
+QSurfaceFormat format = QSurfaceFormat::getDefault();

#ifndef Q_OS_ANDROID
QSurfaceFormat format;
format.setProfile(QSurfaceFormat::CompatibilityProfile);
format.setOption(QSurfaceFormat::DeprecatedFunctions);
//format.setVersion(4,2);
format.setDefault();
#endif

5.1)пытаюсь присобачить флаг -flto, пока не безрезультатно.

6)В андроиде есть libicu, openssl, и libjpeg. Используем их чтоб уменьшить размер библиотек qt. иначе куте с ssl обломится, а jpeg потянет за собой паровозом. Я взял библиотеки из /system/lib, скопировал их на sdcard, и оттуда утащил в NDK. версии библиотек: jpeg6b(пакет libjpeg62-dev), icu44(ахтунг! надо пересобирать для arm), заголовки openssl можно взять любые не сильно воняющие тухлятиной.

Если кому-то будет нужно, выложу переколбашенный qt5.1 и андроидофайлы на сервер.

принимаются идеи и предложения

Есть простейший пример, иллюстрирующий убогость dri. Кстати, эта убогость и в винде есть.

В современных gpu есть вполне нормальные mmu, причем в радеонах их несколько, от 4х в слабых чипах по 16 в топах и si. Тупо несколько mmu, которые работают параллельно. Обычно их все не юзают(на радеонах только vm0 в открытых дровах), но всё можно сделать круче.

Короче, Я предлагаю отказаться от понятия буфера, текстуры и т.д. оставить торчать из ведра вызовы для резервирования памяти на видяхе и remapа. Текстуры можно эмулировать в userspace, а remap вручную позволит избавиться от ttm в ядре, гнусного костыля gem, и флипать doublebuffered текстуры не целиком, а тайлами: очень поможет в плане кпд всяким wayland и dri2, ибо не надо будет перерисовывать все окно изза мелкого обновления

В общем, сама концепция буферов убога. Можно резко упростить dri, и сделать его более гибким.

А вы спорите про то, что лучше : x или wayland. А реформы нужны глубжее, чем смена протокола

Почитал я ради приличия про графен. С ним получается довольно интересная ситуация, ибо он позволяет роиссе рывком догнать загнивающий запад. Ибо медная технология, которую нам не дают, становится не нужна. Гигагерцев просто немерено(пишут по 20ггц на 240нм техпроцессе), а с хитростями - все 100.

This new approach has been instrumental in allowing the researchers to almost quadruple the frequency of graphene chips. Last year, research teams from IBM and the Massachusetts Institute of Technology both demonstrated graphene processors capable of frequencies around 26GHz. By comparison, silicon-based transistors of the same gate length (240 nanometers) have only been able to scale up to a clock rate of 40Ghz or so.

имеется видимо ихняя старая межделмашевскаятехнология Si+C. Нанометры, как видите совсем не мешают.

Как бы и всё, просрали США все свои полимеры. Буквально пара лет и опачки, каждый сможет напечатать процессоров на сраном старом оборудовании.

В общем, дело было так:

На компе были установлены убунтища 12.04 32 бит и 12.04 64 бита, в которых происходила работа. Всё это хозяйство живет на отдельных логических разделах, которые вложены в sda2: убунта32 на sda7, 64 на sda8. sda1 - fat32 раздел на случай установки винды.

Далее для другой работы потребовалась винда8, которая была поставлена на этот же диск на свободное место. И не завелась.

Но она что-то сделала с грубом. Груб загружается и показывает свою консольку. Никаких ошибок не происходит, он видит все свои модули. Командой linux и initrd можно загрузить даже ведро, оно благополучно доходит до консоли initramfs и там остается. Не помогает также grub-install --root-directory=где смонтирована убунта /dev/sda. Не помогла установка убунты с нуля в primary partition(sda4)

Подскажите, что еще можно сделать?

Радостная новость, на радеонах будет работать vaapi. А пилить его будет моё величество. Страшный лютый лисапед xvba будет раскручен на запчасти и сожран на мясо

Вводная: где-то год назад один знакомый гуф придумал как сделать некий CPU и нарисовал на верилоге описание этого CPU. «CPU» умеет за малотранзисторов out-of-order, smp, общий alu для 2х 32bit int/float и 1х int64/double, и в принципе может восстанавливаться после SEU или работать как ядро gpu с фичей preemption-реализация одна. В общем, есть чувство что идея годная. Но гуф хочет из нее сделать деньги, ибо идея год как валяется в чулане.

Гуф может попробовать организовать стартап с другими гуфами, но стартапу потребуется реклама. Ну и патенты оформить еще чтоб было на что кушать. Гуф жопой чувствует что опенсорснуть cpu на условиях типа «GPL или бабло» как было в Qt поможет с рекламой.

Не подскажет ли публика, как это можно сделать в случае железа, чтоб архитектура проца была и запатентованной, и бесплатной для тех, кто сам что-то ваяет(т.е. аналог GPL лицензии на архитектуру нужен)

По патентам - надо от имени стартапа какую-то оферту сделать чтоб её нельзя было отозвать и там было сказано «открыто=бесплатно»?

Т.е. - что сделать чтоб открыть описание железяки для опенсорсников и оставить платным для капиталистических акул? Ткните в howtoшку если знаете

А давайте представим что бы было если бы в байте было 7 бит. Все конечно же подумали про кодировки. Не было бы зоопарка кодировок скорее всего. Ни cp1251, ни koi8-r. Кто с emailами работал тот знает, что такое UTF-7. Ну может быть еще аналог utf8 бы сделали, скажем символы

SO, 0E — Shift Out, измени цвет ленты (использовался для двуцветных лент; цвет менялся обычно на красный). В дальнейшем обозначал начало использования национальной кодировки. SI, 0F — Shift In, обратно к Shift Out.

использовали.

Это мелочь на самом деле. Не туда смотрите.

А вот представьте, что бы стало с х86. Были бы 8086 и 16-килобайтные сегменты. И 2^(14+4)=256кб адресуемой памяти. Кто еще помнит что такое сегмент знает откуда 4ка. Билл гейтс с словами 256 килобайт должно хватить для любых задач-каково? Ну ладно, не дураки тогда были, 256 мало, значит сегмент надо сдвигать больше чем на 4. Если на 6 бит, то получим опять мегабайт. Но наверно сдвигали бы сразу на 7 бит. 2 метра максимум для 8086 а не мегабайт. 7 бит не хватит на фуфлокоманды, так что никаких AAD/AAA/AAC/DAA, однобайтные команды - роскошь.

Дендики бы работали на каких-нибудь 8086 просто потому что Z80 с 16 килобайтами адресов быстро бы всех задолбал. И даже мультиплексирование адресов ему бы не помогло долго продержаться.

С кодировками я погорячился правда. Кто помнит MDA и CGA видеоадаптеры, тот поймет о чем я говорю. Там в ПЗУ были зашиты символы. Инжалид дежице во все поля в этой стране. Бейсик, Паскаль и Си переведены на русский язык.

Если x < 5 то 
начел;
   y = косинус(a)+x;
кончел;
печатай("игрек = %ф\п", у);
збс;

В 80286 скорее всего был бы все тот же лимит в 16 мегабайт, а формат дескриптора бы поменялся. Возможно у него бы были 3 байтные смещения, и их бы хватило многим за глаза 2метровых сегментов. Не было бы стимула делать аналог 32битной flat-памяти.

int far * mydata; char near * ptr; во все поля. Наступает эра 21битных программ. операционная система окна3.0 - теперь 21битная!

Видеоадаптеры EGA с поддержкой национальных кодировок, инжалид дежице уходит в прошлое. А вот с цветами проблема. 4битный цвет с 7битными пикселями сделать сложновато, не находите? Учитывая что на EGA были 4 отдельные фрейбуферы для каждого бита в пикселе, вангую введение 8битного байта на EGA явочным порядком.

у особо прошареных уже есть VGA. 128цветов в палитре - это много.

А потом появился бы 80386 и 4байтные адреса. Максимум 256метров адресуемой памяти.

Выпущен новый 21битный процессор 80486. Лихие 90е. Операционная система окна3.0 живее все живых. Какой-то финский студент просит посмотреть на его программу для терминала. штеуд объявляет о выпуске процессора пентиум. 28битные floatы теперь считаются очень бысто. Где-то к началу 2000х PAE есть во всех процах.

а теперь представьте, что бы было если бы в байте было 9 бит..

Так уж получилось, что я сел и стал писать свою реализацию DRI с шахматами и монашками, и у мну есть вопросы, которые хотелось бы уточнить методомо опроса

Вопрос пользователям амдшных видях:

какие видеокарты у вас есть(vendor/device ids желательно)? muxless/muxed? есть ли AGP?

какие проблемы вы лично испытывали при использовании vgaswitchero?

Какая видеокарта используется по умолчанию, если ничего не переключать? Хотелось бы удостовериться что на ноутах интеграшка первая.

Вопрос возник потому, что в принципе, можно заставить и интеграшку и дискретку юзать одну и ту же область памяти, и работать невзирая на mux.

Вопросы такие оттого, что выкинуть pre-R700 видяшки, AGP, muxed конфигурации, и всегда держать в сознании интеграшку очень удобно. Кстати, последнее с интеграшкой от интела иногда является единственно возможной опцией. mux не проблема сам по себе, но проблема - переключение вдогонку за ним буфера консоли.

Спасибо

есть клип на ютубе: https://www.youtube.com/watch?v=GTrRLNo8zzk и мне надо сделать копию с 2:15 по 2:30, где антенна исчезает.

Чем можно сконвертировать ролик? Я пытался сделать как учили в инетах:

ffmpeg -i Lunarcy_The_Apollo_Fairy_Tale.mp4  -ss 2:18 -t 15 -pix_fmt rgb24 out.gif

convert out.gif -fuzz 3% -layers Optimize out2.gif

Как я писал уже раньше, я делаю нормальное DRI. Абы не изобретать велосипед в плане безопасности, было решено воспользоваться функционалом LSM. Это в теории. Теперь практика:

Мне нужно уметь сделать ровно две вещи:

1)узнать, можно ли обратиться из процесса А в модуль ведра Б

2)узнать, можно ли читать из процесса А данные процесса Б

3)узнать, можно ли управлять из процесса А процессом Б

Подскажите пожалуйста, где(в каком месте) можно прочитать. как пользоваться тем сраным API, которое предоставляется в linux/security.h ? полно мануалов как писать хеловорды но ни одного на тему как сделать свое IPC хотя бы.

пишет про unexpected eof

видимо хочет чтоб я зарегался там у них. но сделать это не получается, тузла пишет:

Making request: GET /subscription/consumers/.blablabal.

Error while updating certifcates using daemon unexpected eof

Я не эксперт по рэдхату. мне просто надо установить gcc и сорцы ведра из репозиторияю. как это сделать?

редхат поставлен с нуля, ничего в нем не менялось. купить лицензию не вариант, мне не нужен редхат, у меня есть убунта с красивым юнити, вырвиглазный второгном не ужасен

через хак с /procfs/self/myfoo, через новое поле в task_struct или как-то еще?

диспозиция такова: есть 2 модуля ядерных, и оба нуждаются в per-process структуре. один создает такую на первом открытии /dev/apu и удаляет когда все файлы /dev/apu которые он открыл(открыть можно много раз), закрыты.

другой вообще занимается сеткой. его можно было бы сделать как security-модуль, но тогда он будет конфликтовать с каким нибудь app-armor(указатель в task-struct один на все модули).

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

статическую rb-tree с мутексом хотелось бы избежать.

почему-то запостился ненабраный псто.

Месяц назад я писал про то, что DRI надо нафиг переписать, а имеющееся засыпать солью и вбить крест в грудь, чтоб не оживало. Так вот, я сейчас работаю на этим, и по ходу работы у меня возникают вопросы.

Для начала что у нас есть. Общая архитектура такова:

приложение->opengl/openvl/foo->usermode_driver->(kernel)->новое DRI->kernelmode_driver->hardware.

«новое DRI» - это то, что я пилю в данный момент. планируется для начала сделать «новое DRI», фейковый kernelmode_driver для вывода в приложение и далее в иксы :), usermode_driver из llvmа, делающий IR, и «железо» из LLVMа, компилящего IR на своей стороне. тормозить будет адски :)

Вопросы у мня архитектурные.

DRI будет показывать наружу 4 устройства. /dev/gpu - для работы с gpu вида создай текстуру-рисуй треугольник-запусти шейдер-opencl. можно будет открыть только один /dev/gpu на процесс(придется хакать что-то в структурах ведра ибо приоритеты нам тоже понадобятся)

как быть с композитором? я не хочу вводить ограничение «один композитор на 1 тачку». ведь можно отсылать скриншоты еще и панели задач(как в 7ке), другому приложению и т.д.).

возмонжно, можно будет открыть еще один /dev/gpu, сделать на него ioctl и отправить через unix socket композитору. этот fd будет урезан в правах до «только читать текстуру или юзать ее в шейдере». минусы - надо будет делать poll+read вместо одного ioctl или read

ах да. если текстурка помечена как конфиденциальная, то ни её, ни результаты обсчета шейдером получить обратно уже будет низя. чтоб не скриншотили номера кредиток

/dev/gpu_features - ну вот есть у amd uvd и pcom. их можно будет дергать, а загружаться они будут из огороженного в целях безопасности демона. т.е. шейдер можно будет взять готовый. почему отгорожено будет? чтоб не сломали вас дебажа каталист. катаглист огораживаете аппармором, и этот девайс тоже. оттуда же можно будет рулить питанием.

/dev/gpu_io - управление видеовыходами. опять же отдельное устройство, чтоб никто не загадил экран. только проверенные apparmorом приложения.

/dev/gpu_ctl - для отладки и контроля доступа.

apparmor приведен для примера.

какие-нибудь предложения есть по поводу вышенаписанного?

«Education does not mean teaching people to know what they do not know – it means teaching them to behave as they do not behave.»

как её по русски изложить не коряво?

взято отсюда: http://psychquotes.com/

http://rt.com/art-and-culture/news/great-wall-china-collapse-355/

Бггг.сочинили традисторики китаю историю чтоб было в 100 раз круче чем у всех, а все равно природа берет своё, сколько не выдумывай.

а ведь предупреждали их:

http://lenta.ru/news/2008/12/16/swiss/

не выпендривайтесь, все ходы записаны.

Я смотрю, местные тролики не понимают, в чем проблема в линуксе. Пишут какую-то полнейшую ерунду вроде «у меня невидии в SLI соединены, на каждой свои иксы» и даже не понимают, что стыдно такое писать. Надо говорить «мы уже работаем над поддержкой SLI и скоро выйдут X12 где все будет УМВР» или вообще молчать, чтоб не стибали.

Как устроена графика в винде?

http://msdn.microsoft.com/en-us/library/windows/desktop/bb205075(v=vs.85).aspx

на первом слайде не изображено в общем-то ничего невозможного для линукса. Приложение использует фронтент cairo/qpainter(на слайде он назван DirectX10), тот в свою очередь использует backend - cairo-drm/qpainter-gl(он же user-mode driver), а тот использует libdrm/libgl(он же dxgi).

а что касается иксов, то они на слайде представлены шедулером cmdbufов в ведре, минипортом и собственно железякой. Кстати, микрософт требует от производителей видеокарт поддержки preemption именно потому, что хотят повысить отзывчивость «иксов».

Для тех, кто жить не может без сетевой прозрачности. user-mode драйвер можно переключать. т.е. для приложения работающего по сети bakcendом выступает не qpainter-gl а какой нибудь qpainter-inet.

Короче, для тех кто в танке: с выходом нового поколения видеокарт, иксы в винде будут аппаратными. А в линуксе - софтварно эмулироваться.

Вообще, мне, как человеку, у которого дома линукс на линуксе стоит и линуксом погоняет, весьма неприятно что в линуксе графика через жопу, dbus - решето, для ac97 софта штыкерами рулить не асилили написать и т.д. и т.п.

==я щас еще наброшу==

типа сидит такой Обычный Пользователь, и вдруг решает посмотреть фильм, и такой берет и подключается на локалхост к иксам через сетевую прозрачность и все у него резко работает и фильм показывается с аппаратным ускорением и улучшением цвета.

Ну или там Обычный Геймер сидит и тут резко решает поиграть в кризис и начинает в него играть через сетевую прозрачность иксов и у него все летает быстрее чем в винде потому что крутая архитектура иксов решает.

Или Обычный Пользователь Интернета решает посмотреть жж и решительно запускает через сетевую прозрачность иксов фаерфокс и вот он уже серфит и сайты так быстро открываются и все плавно работает и не тормозит.

ЗЫ: только не случаи вроде «в комп попал снаряд, мамку разорвало на части, проц в порошок рассыпался и зайти можно было только по сети на огрызок»

Как задолбало смотреть на деградантов, агитирующих сидеть на иксах. Для тех, кто хоть немного разбирается в современных GPU - иксы это дикость. Это такое же legacy как терминалы в ядре.

Так получилось, что пока SGI со товарищи занимались ИБД, и надували щеки - вот прям также, как местные ололо, «разбирающиеся в архитектуре иксов», компания микрософт день и ночь думала о том, как сделать графику быстрее. И поэтому майкрософт(а не красноглазые) придумали шейдеры. Поэтому они придумали стандарт на API для ускорения видео. Микрософт а не «опенсорс сообщество» задает направление развития графики.

В невидии, амд и интеле есть подразделения, которые первыми узнают о том, что выйдет новый директХ или новая винда 9. Эти отделы получают список фич, которые будут в винде и бегут к железочникам, чтоб узнать, что есть в железе уже, что будет сделать сложно, а что - дорого по ваттам. После чего начинается перетягивание одеяла между амд, невидией,интелом и микрософтом, где каждая сторона норовит облегчить себе задачу.

А опенсорс идет по остаточному принципу. И главным образом благодарить за это вы должны сраные иксы.

Видите ли, пока микрософт сокращало и упрощало путь от «знаю что рисовать» до железа в линупсе городили, городили, и городили. В седьмой винде приложение создает «адаптер», из него создает «видео-девайс» и настраивает его и начинает скармливать ему GOPы. на выходе оно имеет surfacы, которые можно поставить в очередь «на экран», забрать себе обратно или в текстуру превратить. В ядре только «минипорт» - штука которая умеет готовые пакеты команд скормить в драйвер. Всё. Никаких иксов здесь не задействовано.

То же самое и для 3д: есть api, есть драйвер, есть минипорт. На выходе получаешь surfacы. Их можно поставить в очередь отрисовки(flip queue) откуда их будет подбирать DWM и собирать в окошки.

И то же самое для 2Д. каким надо быть идиотом, чтоб городить всякие XAA/EXA/UXA/XAXAXA вместо того, чтоб дать приложению самому отправлять команды на gpu. Там есть полная поддержка всей графики-2д 3д и видео. тот же интелоGPU можно проинструктировать программой, и он сам будет отдавать команды на blit-функцию, рисовать градиенты, глифы печатать, и кривые малевать.

Вот ровно то же самое делает wayland. он подбирает surfacы из flip queue и собирает их в картинку.

Никакого геморроя с bumblebee и прочими костылями для убогих иксов: surfacы которые видит интегрированное видео - они в памяти. mmapнул памяти, занес ее в GTT интеграшки - есть окно. открыл драйвер мегаgpu, занес в его GTT ту же область. все работает. gpu рисует и блитит, интеграшка под чутким руководством оконного манагера собирает и показывает.

Я думаю, иксмены понимают, что их аргументы «за иксы» - это полный бред. Они отлично понимают, что wayland проще и меньше жрет ресурсов. Они отлично понимают, что рисовать можно и без иксов, и даже удобнее, т.к. нет самодельных проблем с несколькими видяхами. И даже их сетевая прозрачность проигрывает RDP по всем параметрам: флешки звук и даже скорость.

Эти деграданты просто идут на принцип. Все они понимают, поэтому как полоумные повторяют про «сетевую прозрачность»: видят, что ничего больше в активе нет.

я сегодня запостил 2 багрепорта в багзиллу dbusа и даже почти изготовил патчи. но когда стал раскапывать дальше, чтоб убедиться что патчи потокобезопасны, оказалось что нужно еще один багрепорт писать.

однако, моего уровня знания английского не хватает чтоб описать суть проблемы. я не знаю, как по-английски будет «гребаные бородатые ламеры, я хочу чтоб вы сдохли и больше не писали своих глюкодромов». и вообще как правильно написать им, что у них руки из жопы растут?

у них один глобальный мутекс(т.е. они уже говнокодеры) и он снимается когда надо освободить некие данные пользователя. вместо того чтоб складировать их с список и освободить оптом на выходе, эти товарищи сбрасывают блокировку везде где только могут. в итоге весь код состоит из вермишели функций, которые не трогают мутекс, отпускают его, или берут.

в итоге даже каллбек нельзя поставить потокобезопасно. в принципе, потому что вызок каллбэка не подперт мутексом.

да млъ у них вся багзилла состоит из слов sigsegv и crash. это решето в багзилле кстати сплошь sigsegv и crash

а чего стоит код вида:

CONNECTION_LOCK(pending->conn);
...
if(!foo())return FALSE;
...
CONNECTION_UNLOCK(pending->conn);

внутренний голос подсказывает мне, что это надо переписать. однако моих сил не хватит на переписывание dbusозависимых приложений с нуля. кого бы попросить помочь с тестированием в ближайшие 1-2 месяца?

от этого проекта, между прочим, зависит фаервол типа «agnitum outpost» с блокировкой по процессам. потому что решето фаерволом быть не может.