Здравствуйте, Cyberax, Вы писали:

C>>>Можно добавить аннотации на функции, которые чуть выше критичных инлайновых.
Ops>>Ты вообще в курсе, сколько современные компиляторы инлайнят сами?
C>Не так много, как кажется сначала. Попробуй собрать с -O3 и -Os и сам посмотри на разницу.
Мне приходилось пару раз ручками дописывать __noinline, просто потому что разница была где то в мега полтора.

V>>Для абстракции HDC, полученной для поверхности DirectDraw, тоже выполнялось аппаратное ускорение.
CS>Тебя обманули.
Всех обманули: https://www.neowin.net/forum/topic/1036369-did-you-know-all-gdi-apps-render-slower-under-win7/

V>>Любая прорисовка в буферез заднего плана начиналась с последовательности вызовов CreateCompatibleDC/CreateCompatibleBitmap. Такой битмап по-возможности создаётся в видеопамяти (пока там хватает места).
CS>Слушай, прекращай уже фантазировать. Какой нахрен битмап в видеопамяти?
А в чем проблема? Мапим нужные физ страницы из видеопамяти в юзермодное АП и радуемся супер-быстрим блиттингам из невидимого битмапа в экранный. Ну и расстраиваемся медленным чтениям из битмапов.
https://blogs.msdn.microsoft.com/tmulcahy/2009/02/11/windows-and-video-memory/ — особое внимание пунктику 6, в висте это разумеется сломали, в семерке немного починили, и все возрадовались — ура, нормальная ось.
Давно ведь известный метод маркетинга — не сможешь сделать лучше, сделай хуже, а потом исправь. Немножечко — чтоб остался задел на будущее.

CS>

CS>the BitBlt API was hardware accelerated and most other GDI operations were not.<br />
<span class='lineQuote level1'>CS&gt;</span>

Есть такая ф-я GDI AlphaBlend
И была лет 12 назад у меня задача сделать "затененную" копию экрана, ну примерно как сейчас с UACом делается, и кстати для примерно такой же цели, наверно МС у нас идею стырило, да не в этом суть. А суть в том что я заюзал тогда эту самую AlphaBlend и все было замечательно, пока QA не обнаружило, что на одной из систем в результате вместо затененной картинки получается какой-то трэш из сдвинутых строк. Путем локализации бага оказалось что виновата.. видюха (какая — уже не помню)!
Фикс был простой — накропать альфа бленд ручками, получив GetDIBits и просчитав все самому, то есть сделав тот самый CPU rendering. Оно работало сильно медленнее, если засекать фреймы-в-секунды, но на моей задаче это было непринципиально.
А мораль сей басни такова — не только BitBlt хардварно процессился, но еще и AlphaBlend. Дело было, кстати на ХР. Потом на том же железе интереса ради проверил на свежепоявившейся Висте — баг не воспроизводился.
Ну а то что альфабленд уже в те времена процессился хардварно на WS_EX_LAYERED окнах — это по моему и ежу понятно было. Причем работал и per-pixel блендинг, используя 4й канал битмапов. То есть в принципе техническая возможность допилить GDI чтобы BitBlt поддерживал блендинг, заданный в 4м канале битмапов, явно была, но сдвиг парадигмы разработки винды в сторону "каждую новую фичу пишем с нуля, отдельно нанятой командой индусов" как раз начал набирать обороты. Потому сделали совершенно новый WDDM, в котором отломали ускорение GDI, полноэкранную консоль сломали, и объявили курс на светлое будущее в виде Direct *D. А старые технологии развивать — это ведь не модно. Нужо больше баззвордов.

Здравствуйте, Ikemefula, Вы писали:

I>Как работает процессор, дело десятое. x86 хоть и не выполняются напрямую, но обрабатывается специальными устройствами. То есть, тайминги не в твою пользу.
Не распарсил. переведи на русский.

Здравствуйте, Cyberax, Вы писали:

C>Я писал UI на всём, и вот недавно надо было быстро написать десктопную утилитку для моей команды. Я сели и за пару дней написал на Electron то, что на

Можешь продемонстрировать? Мне реально интересно, что же там такое, чего нельзя сделать в WPF быстро.

C>Неа. WPF — то ещё уродство, порождённое XML-чудищами.

Там всю стандартную функциональность можно сделать даже не особо заглядывая в XAML. Максимум — для центрирования скопипастить пару раз из stackoverflow.

Здравствуйте, koandrew, Вы писали:

I>>Как работает процессор, дело десятое. x86 хоть и не выполняются напрямую, но обрабатывается специальными устройствами. То есть, тайминги не в твою пользу.
K>Не распарсил. переведи на русский.

Что происходит с x86, и что происходит с обычным байткодом это вещи мягко говоря не сравнимые, например, по временным затратам.

Здравствуйте, Ikemefula, Вы писали:

I>Что происходит с x86, и что происходит с обычным байткодом это вещи мягко говоря не сравнимые, например, по временным затратам.
x86 и есть байт-код. Вся разница с IL/жабовским байткодом лишь в наборе команд и в том, что у x86 есть аппаратная VM.

Здравствуйте, netch80, Вы писали:

V>>Ну конечно, только такая мультимедийные архитектуры, как Эльбрус или IA64 максимально уместны.
N>IA64 мультимедийный — тянет на шутку дня. Ты точно не начал опять путать VLIW и SIMD?

Нет, не начал.
IA64 — классика VLIW.
На той же частоте показывала лучшие результаты в математике, чем современные ей процы IA32.


N>А теперь непонятно, зачем смешивать VLIW не то с GPU, не то с выделенным видеопроцессором.

Суть вопроса опять ускользает от меня.


N>>>Структура команды? Так после блока разбора переменность длины и всякие префиксы/суффиксы уже пофиг. А вот необходимость связывать в бандлы — мешает.
V>>Не вижу раскрытия темы.
N>Какое слово непонятно? (tm)

Слова понятны, раскрытия темы нет.


V>>Как раз операционка может использовать одни регистры, прикладные приложения — другие, причем разные.
V>>Для текущего потока один раз выставляет адрес "окна" регистров.
V>>Оч удобно, как по мне. Можно добиться, чтобы было меньше свопа регистрового файла при переключении контекстов/потоков.
N>Ты, по-моему, начал рассказывать про SPARC.

Архитектура близка к PA-RISC, но речь, таки, об IA64:

GR32-127 — стекируемые регистры.
Стекируемые регистры становятся доступными в программной единице через окно стека регистров

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


N>У IA64 это всё значительно муторнее — никто не гарантирует полный круг больше стандартных 96, и штатно переключения контекстов требуют полного сохранения.

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


V>>Самая большая ложь, которую я вижу тут постоянно. ))
V>>Переименование регистров не решает проблему кучи лишних пар PUSH/POP, вызванных этой неуниверсальностью.
N>Есть какие-то реальные цифры количества этих "кучи лишних"?

Что мешает посмотреть ассемберный выход любой твоей сишной программы под IA32?
Там до 30% всех команд — это PUSH/POP.
Собсно, архитектуру IA32 материли за это и только это.
Вернее, материли причины, по которым так выходит.


N>>>Дешевле что именно?
V>>Производительность к кол-ву транзисторов.
N>Есть где-то надёжные данные? Или только реклама от Intel?

А есть где-то опровержение "рекламы"? ))
В общем, не надо вот этих манипуляций ярлыками. Есть некие официальные характеристики процессора, есть некие официальные данные о кол-ве транзисторов в нём. Думаю, независимые умельцы давно бы с шумом опровергли, если бы оно было не так.


N>>>Дальше блоки предсказаний и разбора кода — ну, вот на последнем можно кое-как сэкономить.
V>>А это, батенька, у нас основной тепловыделитель, то бишь ограничитель частоты.
N>Ну вот потому я и говорю, что было что исправлять.

VLIW — это и есть попытка такого исправления.
Приличная доля тепловыделения переносится на стадию компиляции/оптимизации.


N>>>Причём воспользоваться минимальными усилиями в плане собственно компиляции (open64 вообще на коленке сляпан, а доработать gcc было легко
V>>Да как легко-то? Куча новых регистров (Rx), способ линковки и релокации символов другой совершенно.
V>>Всё это потребовало денег и людских ресурсов.
N>Ну ведь меньше, чем на IA64 с совершенно новой логикой всего?

Ес-но. Но и масштабы Intel и AMD малость несравнимы.


V>>Собсно, цель была дать возможности работать 32-разрядным приложениям в 64-битной ОС. Только научив свою архитектуру такой работе можно было выжить. Вот с этим моментом они справились просто на отлично. Согласись, что остальные моменты на фоне этого, главного, просто меркнут.
N>В краткосрочной перспективе (5 лет) — да. В большей — нет. Уже более 15.

ХЗ. До сих пор 32-х разрядные приложения цветут и пахнут. Потому что полно задач, где этого достаточно сегодня и еще долго будет достаточно тоже.


V>>Ну, они украли дековскую Альфу и наш Эльбрус. Им надо было конвертировать наворованно в прибыль "сейчас", а не "потом". ))
N>Насчёт "украли" не буду влезать, но хочу заметить, что в IA64 что-то не видно специфичных особенностей ни Альфы, ни того старого Эльбруса.

Ну, т.е., Intel напрасно отстегнула кучу бабла на покупку всей интеллектуальной собственности, относящейся к Альфе?
Временное помутнение у них случилось или как?

Ну реально, что мне отвечать на такое: "я не вижу специфичных особенностей"...
А куда мы смотрим-то?

Проц Альфа был описан полностью на Верилоге, но разведён вручную. Именно поэтому им удалось так поднять свою частоту — это же тот самый феноменальный исторический курьёз вокруг Альфы (он же единственный, кста).

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

Я лишь напомню, что после покупки Альфы, Intel очень быстро довела свою тактовую до почти 4-х ГГЦ, в то время как конкурентам оставалось лишь указывать не тактовую, а некий "индекс производительности" по отношению к тактовой сравнимого по кол-ву выч. блоков и размеров кешей процессора Интел.

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


N>>>А так — попытка построения в 2000 на концепциях в лучшем случае начала 90-х. Если не раньше.
V>>Э-э-э... Давай уточним. Речь идёт о концепциях суперкомпьютеров, которые (концепции) решили применить в декстопном проце.
N>Это с чего это VLIW — концепция суперкомпьютера?

Да так повелось еще с середины 80-х...
До сих пор эти компы работают в составе ПВО Москвы, если вики не врёт.


N>>>2. Оно само разбирает цикл уже на этапе JIT или native generation. На уровне IL это цикл.
V>>Дык, на уровне исходника тоже цикл. Ничего не меняется, оптимизирующий компилятор должен этот IL преобразовать.
N>Ну а я говорил о записи в самом IL. Так что не то.

Ну, мало ли, что ты говорил. IL-это языконезависимый объектный код, более никакой нагрузки ему нести не обязательно — это прямо согласно его задумке, если что.

Далее.
Любая векторная оптимизация предполагает вполне конкретное кол-во векторных регистров и вполне конкретный набор операций над ними + информация о стоимости этих операций. В этих ограничениях и производится поиск оптимума.

ИМХО, очевидно же, что если внести подобные ограничения в IL, то это лишь затруднит перенос на другие векторные модели, бо перед этим опять надо будет получить исходную семантику (которая была ДО всяческих оптимизаций), а потом уже повторно отобразить эту исходную семантику на конкретный расклад в некоей железке. Извращение? — оно самое. ))


N>>>Я бы скорее ожидал что-то в духе Agnerʼовского ForwardCom (где длина вектора, обработанного одной командой, в принципе не ограничена) — переложить это на конкретную ограниченную длину уже банально. Хотя и оно заточено под текущую схему концепций соотношения команды и кэша.
V>>Ну это когда оптимизатор совсем уж тупой. ))
N>А зачем на него водружать то, что способен сделать компилятор в IL

Для выполнения прямой своей задачи, вестимо, — абстрагирования от конкретной железки.

Здравствуйте, koandrew, Вы писали:

I>>Что происходит с x86, и что происходит с обычным байткодом это вещи мягко говоря не сравнимые, например, по временным затратам.
K>x86 и есть байт-код. Вся разница с IL/жабовским байткодом лишь в наборе команд и в том, что у x86 есть аппаратная VM.

Спасибо за уточнение. Речь перед этим была про компромиссы. Как думаешь, x86 это компромисс или "байткод позволяет обойтись без компромиссов" ?

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, c-smile, Вы писали:

I>>>Растр ни при чем. Растром в браузере можно рисовать не хуже чем в нативном виндовском апи.

CS>>Хуже. Проблема в том что спецификация <canvas> требует чтобы рисовалось в bitmap. Соответственно там CPU rendering.

I>Даже такого рендеринга за глаза хватит, что бы рисовать быстро.

Смотря что рисовать.
Вот например http://corehtml5canvas.com/code-live/ch05/example-5.19/example.html
Грузит одно ядро процессора полностью.

Ну и потом в UI нужно рисовать не только быстро но и экономно.

Здравствуйте, ononim, Вы писали:

V>>>Для абстракции HDC, полученной для поверхности DirectDraw, тоже выполнялось аппаратное ускорение.
CS>>Тебя обманули.
O>Всех обманули: https://www.neowin.net/forum/topic/1036369-did-you-know-all-gdi-apps-render-slower-under-win7/

Абсолютно верно.
Я рядом писал:

До Win7 ты вообще рисовал ПРЯМО в видеопамять.
То бишь, когда ты получал HDC текущего окна для прорисовки, ты получал DC над экранным буфером видеопамяти.
Причем, доступ к отображаемому в данный момент видеобуферу — он на тех карточках всегда был более медленный, чем к заднему буферу.

В Висте/Win7 и выше ты больше не пишешь прямо в экранный буфер, поэтому, когда ты растягиваешь окно, то опять появляются артефакты — черные или белые "пустые" области, пока приложение там прорисует в свой буфер.

O>Ну а то что альфабленд уже в те времена процессился хардварно на WS_EX_LAYERED окнах — это по моему и ежу понятно было. Причем работал и per-pixel блендинг, используя 4й канал битмапов. То есть в принципе техническая возможность допилить GDI чтобы BitBlt поддерживал блендинг

А какую из операций? Простое смешение?
Сигнатура AlphaBlend построена так, чтобы задавать любые blend-операции над src и dst, хотя изначально было реализовано лишь простое смешение + доп. множитель альфа.


O>в котором отломали ускорение GDI, ... и объявили курс на светлое будущее в виде Direct *D.

И это дало свои плоды в DirectX 11/12, где на многих классах задач получили ускорение до 2-х раз.

O>>Ну а то что альфабленд уже в те времена процессился хардварно на WS_EX_LAYERED окнах — это по моему и ежу понятно было. Причем работал и per-pixel блендинг, используя 4й канал битмапов. То есть в принципе техническая возможность допилить GDI чтобы BitBlt поддерживал блендинг
V>А какую из операций? Простое смешение?
V>Сигнатура AlphaBlend построена так, чтобы задавать любые blend-операции над src и dst, хотя изначально было реализовано лишь простое смешение + доп. множитель альфа.
SetAlphaMode, очевидно же. С дефолтовым AM_NONE — для совместимости


O>>в котором отломали ускорение GDI, ... и объявили курс на светлое будущее в виде Direct *D.
V>И это дало свои плоды в DirectX 11/12, где на многих классах задач получили ускорение до 2-х раз.
Не уверен что этого нельзя было достичь не отламывая ускорение от GDI.

Здравствуйте, ononim, Вы писали:

O>А мораль сей басни такова — не только BitBlt хардварно процессился, но еще и AlphaBlend.

AlphaBlend это не GDI. Эта функция живет/жила в msimg32.dll что как бы намекает.
Фактически же это надстройка над BitBlt поэтому можно говорить что она тоже "accelerated".

В GDI принципиально не было функций для работы с альфаканалом.
Даже более того, все попытки вывода с пом. GDI функций в DC over 32-bit DIB приводили к печальным результатам.
TextOut например в A канал принудительно записывал 0. Какие-то другие функции A канал вообще не трогали, другие же ставили туда 0xFF.
В общем каша.

В результате в HTMLayout я использовал AGG от Макса Шеманарева (земля ему пухом).
Да и работал AGG быстрее чем тот "hardware accelerated GDI" (с) vdimas.

Проблема в том что и AGG и GDI растеризация (что не есть BitBlt, sic!) это всегда O(N) complexity (N — количество пикселей на экране).
Т.е. имеет крайне ограниченное применение в современных desktop.

Здравствуйте, c-smile, Вы писали:

CS>Смотря что рисовать.
CS>Вот например http://corehtml5canvas.com/code-live/ch05/example-5.19/example.html
CS>Грузит одно ядро процессора полностью.

Сколько там кадров выходит в секунду ? Чтото мне кажется, в каком нибудь GDI+ будет ровно то же.

CS>Ну и потом в UI нужно рисовать не только быстро но и экономно.

Ну вот, нужно сделать стрелочку что бы бежала как в механических часах, 6-8 полуколебаний, или в кварцевых, по секунде

O>>А мораль сей басни такова — не только BitBlt хардварно процессился, но еще и AlphaBlend.
CS>AlphaBlend это не GDI. Эта функция живет/жила в msimg32.dll что как бы намекает.
Это GDI: https://msdn.microsoft.com/library/windows/hardware/ff556176
Более того, у меня есть под рукой виртуалка с XP и IDA и легкий дизасминг показал что msimg32!AlphaBlend в ней — это проверка параметров и вызов в gdi32!GdiAlphaBlend:

	которая выглядит так
	; Exported entry 242. GdiAlphaBlend ; ЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫ S U B R O U T I N E ЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫ ; Attributes: bp-based frame ; int __stdcall GdiAlphaBlend(int,int,int,int,int,HDC hdc,int,int,int,int,__int16) public _GdiAlphaBlend@44 _GdiAlphaBlend@44 proc near ; CODE XREF: GdiDrawStream(x,x,x)+22AD8p ; MRALPHABLEND::bPlay(void *,tagHANDLETABLE *,uint)+100p arg_0 = dword ptr 8 arg_4 = dword ptr 0Ch arg_8 = dword ptr 10h arg_C = dword ptr 14h arg_10 = dword ptr 18h hdc = dword ptr 1Ch arg_18 = dword ptr 20h arg_1C = dword ptr 24h arg_20 = dword ptr 28h arg_24 = dword ptr 2Ch arg_28 = word ptr 30h ; FUNCTION CHUNK AT 77F26B53 SIZE 00000072 BYTES ; FUNCTION CHUNK AT 77F38337 SIZE 00000025 BYTES mov edi, edi push ebp mov ebp, esp push ebx push esi xor esi, esi cmp [ebp+hdc], esi push edi jz loc_77F26BBE mov ecx, [ebp+hdc] mov eax, 7F0000h and ecx, eax mov edx, 660000h cmp ecx, edx jz loc_77F26BBE mov ebx, [ebp+arg_0] mov ecx, ebx and ecx, eax mov edi, 10000h cmp ecx, edi jnz loc_77F26B53 loc_77F1A7CF: ; CODE XREF: GdiAlphaBlend(x,x,x,x,x,x,x,x,x,x,x)+C422j ; GdiAlphaBlend(x,x,x,x,x,x,x,x,x,x,x)+1DBBAj mov eax, large fs:18h push esi push dword ptr [ebp+arg_28] mov [eax+6D0h], esi push [ebp+arg_24] push [ebp+arg_20] push [ebp+arg_1C] push [ebp+arg_18] push [ebp+hdc] push [ebp+arg_10] push [ebp+arg_C] push [ebp+arg_8] push [ebp+arg_4] push ebx call _NtGdiAlphaBlend@48 ; NtGdiAlphaBlend(x,x,x,x,x,x,x,x,x,x,x,x) loc_77F1A800: ; CODE XREF: GdiAlphaBlend(x,x,x,x,x,x,x,x,x,x,x)+C42Fj pop edi pop esi pop ebx pop ebp retn 2Ch

CS>Фактически же это надстройка над BitBlt поэтому можно говорить что она тоже "accelerated".
Учитывая вышенаписанное — данное утверждение — ложный домысел, как и все остальное, поскипанное.
Впрочем, надо уточнить, что видеодрайвер волен выбирать реализовывать ли конкретную ф-ю аппаратно или нет. Возможно, вам просто не повезло с видеодрайвером. Здесь подробнее: https://docs.microsoft.com/en-us/windows-hardware/drivers/display/hooking-versus-punting

Здравствуйте, ononim, Вы писали:

O>которая выглядит так

То что AlphsBlend может заканчиваться вызовом функции драйвера — вопросов нет.
Но то что драйвер это всегда hardware accelerated код — т.е. что-то транслируемое в команды GPU — совершенно не факт.

На самом же деле мы обсуждаем несколько иную ситуацию, а именно утверждение что GDI hardware accelerated.
В этом утверждении правда только в том что только функции семейства BitBlt ( т.е. трансфер bitmaps туда обратно ) еще как-то accelerated.
Все остальное, типа LineTo, PolyBezierTo и пр. — нет.

Если же говорить про твой пример с WS_EX_LAYERED то рисование (GDI) там это всегда in-memory bitmap и вызов UpdateLayeredWindow() с тем bitmap.
Т.е. это всегда CPU rasterization.

С Direct2D можно это устроить несколько более эффективно используя DirectX texture на ID3DXXDevice и CreateDxgiSurfaceRenderTarget сверху, т.е. на стороне GPU.
А еще лучше через DirectComposition, но это уже отдельная песня.

CS>То что AlphsBlend может заканчиваться вызовом функции драйвера — вопросов нет.
CS>Но то что драйвер это всегда hardware accelerated код — т.е. что-то транслируемое в команды GPU — совершенно не факт.
Да и вообще не факт что этот мир — не сон Ктулху.

CS>На самом же деле мы обсуждаем несколько иную ситуацию, а именно утверждение что GDI hardware accelerated.
CS>В этом утверждении правда только в том что только функции семейства BitBlt ( т.е. трансфер bitmaps туда обратно ) еще как-то accelerated.
CS>Все остальное, типа LineTo, PolyBezierTo и пр. — нет.
Это верно только для семерки. Для ХР LineTo/AlphsBlend ускорялось, PolyBezierTo — вот действительно нет. Список функций которые были ускорябельны — по ссылке что я уже приводил.

CS>Если же говорить про твой пример с WS_EX_LAYERED то рисование (GDI) там это всегда in-memory bitmap и вызов UpdateLayeredWindow() с тем bitmap.
CS>Т.е. это всегда CPU rasterization.
Ох. НЕТ. Вам уже писали, и ссылки приводили — что device-dependent битмап — это видеопамять видюхи, UpdateLayeredWindow — ускоряеся драйвером, функции которые XPDM драйвером должны для этого имплементиться — список выше. Но вы почему-то логике не внемлете, зациклившись по кругу.

CS>С Direct2D можно это устроить несколько более эффективно используя DirectX texture на ID3DXXDevice и CreateDxgiSurfaceRenderTarget сверху, т.е. на стороне GPU.
CS>А еще лучше через DirectComposition, но это уже отдельная песня.
Больше угара — больше баззвордов!

Здравствуйте, ononim, Вы писали:

O>>>в котором отломали ускорение GDI, ... и объявили курс на светлое будущее в виде Direct *D.
V>>И это дало свои плоды в DirectX 11/12, где на многих классах задач получили ускорение до 2-х раз.
O>Не уверен что этого нельзя было достичь не отламывая ускорение от GDI.

А зачем?
В Direct2D добавили построение эллипсов и глифов, а так же ввели, наконец, сокращенную матрицу преобразований (только по 2-м координатам).
В этом случае достаточно транслировать вызовы GDI в соотв. операции D2D, т.е. обыграв такую трансляцию на уровне драйвера, не нагружая карточку лишним функционалом.

Причем, такая возможность была предоставлена даже для явного использования как в D2D, так и в DXGI:
https://msdn.microsoft.com/en-us/library/ff471343(v=vs.85).aspx

Здравствуйте, ononim, Вы писали:

O>Ох. НЕТ. Вам уже писали, и ссылки приводили — что device-dependent битмап — это видеопамять видюхи, UpdateLayeredWindow — ускоряеся драйвером, функции которые XPDM драйвером должны для этого имплементиться — список выше. Но вы почему-то логике не внемлете, зациклившись по кругу.

Ох ё-моё еще один фантазер.

device-dependent bitmap (DDB) это т.н. compatible bitmap.

Сompatible bitmap это bitmap совместимая по layout и color organization c каким-нибудь device. ЭТО НЕ ЕСТЬ bitmap в видео памяти. У CPU вообще нет доступа к видео памяти в том же виде что и основной памяти. Когда-то в древности такое было на каком-нибудь Z80, но уже давно как нет.

To use a DDB in a device context, it must have the color organization of that device context. Thus, a DDB is often called a compatible bitmap and it usually has better GDI performance than a DIB.

И вот тебе цитата из Феня нашего Юаня:

Windows Graphics Programming: Win32 GDI and DirectDraw By Feng Yuan

DDBs are stored into GDI's 32-bit heap. ... DDBs are allocated off the paged-pool, which lives in kernel address space

Короче, учите господа матчасть.

Здравствуйте, vdimas, Вы писали:

V>>>Ну конечно, только такая мультимедийные архитектуры, как Эльбрус или IA64 максимально уместны.
N>>IA64 мультимедийный — тянет на шутку дня. Ты точно не начал опять путать VLIW и SIMD?
V>Нет, не начал.
V>IA64 — классика VLIW.
V>На той же частоте показывала лучшие результаты в математике, чем современные ей процы IA32.

В математике... это с FPU с его дебильным стеком? В любом случае, нормальная оптимизация математики в x86 началась уже где-то после Nehalem. Это не оправдание Intel за торможение, но никак не аргумент против x86.

N>>А теперь непонятно, зачем смешивать VLIW не то с GPU, не то с выделенным видеопроцессором.
V>Суть вопроса опять ускользает от меня.

Всё ты понимаешь. Точно так же, как в следующем вопросе.

V>>>Как раз операционка может использовать одни регистры, прикладные приложения — другие, причем разные.
V>>>Для текущего потока один раз выставляет адрес "окна" регистров.
V>>>Оч удобно, как по мне. Можно добиться, чтобы было меньше свопа регистрового файла при переключении контекстов/потоков.
N>>Ты, по-моему, начал рассказывать про SPARC.
V>Архитектура близка к PA-RISC, но речь, таки, об IA64:
V>

V>GR32-127 — стекируемые регистры.
V>Стекируемые регистры становятся доступными в программной единице через окно стека регистров

Про возможность, что больше одного окна просто не влезет, я уже сказал. У SPARC даже в младших моделях гарантируется место для нескольких окон.

N>>У IA64 это всё значительно муторнее — никто не гарантирует полный круг больше стандартных 96, и штатно переключения контекстов требуют полного сохранения.
V>Первые 8 регистров по спецификации ОС отведены под задачи ядра. Прикладным процессам они доступны только для чтения, что позволяет возвращать довольно много инфы из ядра прямо в регистрах и не свопить регистры при смене контекстов с юзверского на ядерный.

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

V>>>Самая большая ложь, которую я вижу тут постоянно. ))
V>>>Переименование регистров не решает проблему кучи лишних пар PUSH/POP, вызванных этой неуниверсальностью.
N>>Есть какие-то реальные цифры количества этих "кучи лишних"?

V>Что мешает посмотреть ассемберный выход любой твоей сишной программы под IA32?
V>Там до 30% всех команд — это PUSH/POP.

$ F=/usr/local/bin/bash
$ objdump -d "$F" | grep '^ 8' | wc -l
  200073
$ objdump -d "$F" | grep '^ 8' | egrep -w 'push|pop' | wc -l
   10928
$ F=/usr/local/bin/centerim 
$ objdump -d "$F" | grep '^ 8' | wc -l
  481060
$ objdump -d "$F" | grep '^ 8' | egrep -w 'push|pop' | wc -l
   26090
$ F=/usr/libexec/sendmail/sendmail 
$ objdump -d "$F" | grep '^ 8' | wc -l
  142354
$ objdump -d "$F" | grep '^ 8' | egrep -w 'push|pop' | wc -l
    4541
$ uname -m
i386

Это 4-5%, а не 30%. В байтах — ещё меньше. Так на чём основаны твои странные фантазии? Ах да, ты ещё не определил, сколько из этих PUSH/POP вызваны зависимостью от прибитых назначений регистров, а не естественной необходимостью в регистрах и сохранения их старых значений. А судя по тому, что я вижу в выходном коде, этих случаев жалкие дольки. То есть от 5% получаем менее 1%.

N>>>>Дешевле что именно?
V>>>Производительность к кол-ву транзисторов.
N>>Есть где-то надёжные данные? Или только реклама от Intel?
V>А есть где-то опровержение "рекламы"? ))
V>В общем, не надо вот этих манипуляций ярлыками. Есть некие официальные характеристики процессора, есть некие официальные данные о кол-ве транзисторов в нём. Думаю, независимые умельцы давно бы с шумом опровергли, если бы оно было не так.

Отсылка к чужому авторитету без конкретики А говорил, инженер...

N>>>>Дальше блоки предсказаний и разбора кода — ну, вот на последнем можно кое-как сэкономить.
V>>>А это, батенька, у нас основной тепловыделитель, то бишь ограничитель частоты.
N>>Ну вот потому я и говорю, что было что исправлять.
V>VLIW — это и есть попытка такого исправления.
V>Приличная доля тепловыделения переносится на стадию компиляции/оптимизации.

Дык не работает же этот перенос.

V>>>Собсно, цель была дать возможности работать 32-разрядным приложениям в 64-битной ОС. Только научив свою архитектуру такой работе можно было выжить. Вот с этим моментом они справились просто на отлично. Согласись, что остальные моменты на фоне этого, главного, просто меркнут.
N>>В краткосрочной перспективе (5 лет) — да. В большей — нет. Уже более 15.
V>ХЗ. До сих пор 32-х разрядные приложения цветут и пахнут. Потому что полно задач, где этого достаточно сегодня и еще долго будет достаточно тоже.

Я говорил об оценке качества полученного 64-битного решения.

V>>>Ну, они украли дековскую Альфу и наш Эльбрус. Им надо было конвертировать наворованно в прибыль "сейчас", а не "потом". ))
N>>Насчёт "украли" не буду влезать, но хочу заметить, что в IA64 что-то не видно специфичных особенностей ни Альфы, ни того старого Эльбруса.

V>Ну, т.е., Intel напрасно отстегнула кучу бабла на покупку всей интеллектуальной собственности, относящейся к Альфе?
V>Временное помутнение у них случилось или как?

Что тебя удивляет? Вспомни Rambus.

V>Ну реально, что мне отвечать на такое: "я не вижу специфичных особенностей"...
V>А куда мы смотрим-то?
V>Проц Альфа был описан полностью на Верилоге, но разведён вручную. Именно поэтому им удалось так поднять свою частоту — это же тот самый феноменальный исторический курьёз вокруг Альфы (он же единственный, кста).

V>Описание проца на верилоге — это тысячи прикладных компонент + соответствующая им разметка чипа, которая позволила на том же технологическом процессе получить почти вдвое большую максимальную тактовую в сравнении с конкурентами.

V>Я лишь напомню, что после покупки Альфы, Intel очень быстро довела свою тактовую до почти 4-х ГГЦ,

"Разведён вручную" — это штучная работа, которая не переносится на другие процессоры. Intelʼу этот результат не мог пригодиться. Ты, небось, представляешь себе вариант типа: Intel разбирает документацию Alpha, чтобы понять причину такой высокой скорости, и находит конверт надписью "Наша самая секретная технология", а внутри одна фраза — "Сборка трезвым"? Ты явно слишком много пересмотрел Голливуда или российских сериалов.

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

V> в то время как конкурентам оставалось лишь указывать не тактовую, а некий "индекс производительности" по отношению к тактовой сравнимого по кол-ву выч. блоков и размеров кешей процессора Интел.

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

Через 5 лет и Intel понял, какой получился пшик, и применил голову — получился Core.

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

Информация прорывается. Тем более для такого старого и важного объекта. Те же особенности устройства P-IV очень хорошо вычислены исследователями. Можешь поискать статью — где рассказывали, как из-за слишком тупого синхронизатора команды могли по 40 раз уходить на следующую попытку выполниться.

N>>>>А так — попытка построения в 2000 на концепциях в лучшем случае начала 90-х. Если не раньше.
V>>>Э-э-э... Давай уточним. Речь идёт о концепциях суперкомпьютеров, которые (концепции) решили применить в декстопном проце.
N>>Это с чего это VLIW — концепция суперкомпьютера?
V>Да так повелось еще с середины 80-х...
V>До сих пор эти компы работают в составе ПВО Москвы, если вики не врёт.

SIMD. А не VLIW.

N>>>>2. Оно само разбирает цикл уже на этапе JIT или native generation. На уровне IL это цикл.
V>>>Дык, на уровне исходника тоже цикл. Ничего не меняется, оптимизирующий компилятор должен этот IL преобразовать.
N>>Ну а я говорил о записи в самом IL. Так что не то.
V>Ну, мало ли, что ты говорил. IL-это языконезависимый объектный код, более никакой нагрузки ему нести не обязательно — это прямо согласно его задумке, если что.

V>Далее.
V>Любая векторная оптимизация предполагает вполне конкретное кол-во векторных регистров и вполне конкретный набор операций над ними + информация о стоимости этих операций. В этих ограничениях и производится поиск оптимума.

Любая не-векторная оптимизация точно так же "предполагает" конкретное количество простых регистров. Не так ли? Но тем не менее IL пишется в формулировках типа "я требую N локальных переменных", а распределять их по реальным регистрам будет уже генератор нативного кода.

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

V>ИМХО, очевидно же, что если внести подобные ограничения в IL, то это лишь затруднит перенос на другие векторные модели, бо перед этим опять надо будет получить исходную семантику (которая была ДО всяческих оптимизаций), а потом уже повторно отобразить эту исходную семантику на конкретный расклад в некоей железке. Извращение? — оно самое. ))

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

N>>>>Я бы скорее ожидал что-то в духе Agnerʼовского ForwardCom (где длина вектора, обработанного одной командой, в принципе не ограничена) — переложить это на конкретную ограниченную длину уже банально. Хотя и оно заточено под текущую схему концепций соотношения команды и кэша.
V>>>Ну это когда оптимизатор совсем уж тупой. ))
N>>А зачем на него водружать то, что способен сделать компилятор в IL
V>Для выполнения прямой своей задачи, вестимо, — абстрагирования от конкретной железки.

Так вот тут и показывают абстрагирование, а ты сопротивляешься.

Здравствуйте, c-smile, Вы писали:

CS>device-dependent bitmap (DDB) это т.н. compatible bitmap.

CS>Сompatible bitmap это bitmap совместимая по layout и color organization c каким-нибудь device. ЭТО НЕ ЕСТЬ bitmap в видео памяти. У CPU вообще нет доступа к видео памяти в том же виде что и основной памяти. Когда-то в древности такое было на каком-нибудь Z80, но уже давно как нет.

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

CS>

CS>DDBs are stored into GDI's 32-bit heap. ... DDBs are allocated off the paged-pool, which lives in kernel address space

CS>Короче, учите господа матчасть.

То есть, ты имеешь сказать, что все в памяти ? Раз так, то в чем будет отличие в рисовании стрелки в твоём примере относительно канваса ?