LINUX.ORG.RU

Взаимодействие между программным и аппаратным рендерингом

 , ,


1

1

Как в тулкитах совмещается программный и аппаратный рендеринг так чтобы не было тормозов при копировании из/в видеопамять и чтобы не было избыточных буферов/копирования? Далеко не всё рисование в тулкитах делается через GPU. Можно примеры на места в коде реализации тулкитов.

В частности интересно возможно ли нарисовать буфер в RAM на OpenGL рендербуфере с клиппингом без дополнительных буферов и копирований? Буфер в RAM можно выделить с необходимым выравниванием и прочими параметрами если требуется.

★★★★★
Ответ на: комментарий от anonymous

Intel могут подсуетиться и обойти этот M1. Там тоже встроенная графика с общей памятью. Массовый переход на Маки – несбыточная мечта фанатиков.

X512 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Вот когда дойдёт - возвращайся. Сейчас, на практике, все такие системы - тормозое дерьмо.

anonymous
()
Ответ на: комментарий от eternal_sorrow

Далеко не всё рисование в тулкитах делается через GPU

и это плохо

Вот когда драйвера видеокарт научаться делать без багов, тогда и говори такие вещи.

Исполнение кода на GPU это быстро, но потенциально глючно. Ты не знаешь, как будет вести такое ПО с конкретной видеокартой, ОС, и конкретной версией драйверов.

pathfinder ★★★★
()
Ответ на: комментарий от anonymous

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

а может быть ты просто рофлеротроль.

safocl ★★
()
Ответ на: комментарий от anonymous

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

по этому твое мнение полностью повержено.
смешные аноны последнее время пошли.

safocl ★★
()
Ответ на: комментарий от anonymous

битва двух анонов — а может это один человек — просто раздвоение битов...

safocl ★★
()
Ответ на: комментарий от safocl

векторное обрабатывание данных (такое как расчет цвета пикселей)

Пиксели – это же растр. Вектор – это треугольники, полигоны, Безье и т.д.. С векторной графикой видеокарта плохо умеет работать.

X512 ★★★★★
() автор топика
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от X512

С векторной графикой видеокарта плохо умеет работать.

Вы еще скажите, что OpenGL не умеет треугольник нарисовать …

anonymous
()
Ответ на: комментарий от X512

эммм... как бы я про одновременное применение действий сразу к нескольким значениям...
в ЦПУ это avx и подобное...
а видеокарта для этого и создавалась.

safocl ★★
()
Ответ на: комментарий от anonymous

ну да — кстати как бы видеокарта просто не может никак сравниваться по скорости отрисовки треугольника с ЦПУ — второй будет на множество порядков медленнее делать это

safocl ★★
()
Ответ на: комментарий от X512

С векторной графикой видеокарта плохо умеет работать.

Кстати, для OpenGL имеется API, заточенное для использования векторной графики?
Если нет, то нужно бы разработать …

anonymous
()
Ответ на: комментарий от anonymous

И эшо …

Кстати, для OpenGL имеется API, заточенное для использования векторной графики? Если нет, то нужно бы разработать …

По существу лаба для студентов.
Начну делать GUI и если готового API не будет, то разработаю …

anonymous
()
Ответ на: комментарий от anonymous

Вы еще скажите, что OpenGL не умеет треугольник нарисовать …

Кривые Безье, невыпуклые и самопересекающиеся кривые видеокарта рисовать не умеет насколько я знаю. Надо на CPU либо триангулировать, либо растеризовать в маску альфа-канала.

X512 ★★★★★
() автор топика
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от anonymous

Продолжение эшо …

GUI будет кроссплатформенным: Linux и Windows, что касаемо хайки, то надеюсь проблем к адаптации не будет.

Кстати, все ратуют за кроссплатформенность, а она как бы подразумевает возможность работы с приложением и в Windows.

Но вот парадокс!
Кроссплатформенность приветствуем, а разговоры о Windows

ЕРЕСЬ

Какая-то инквизиция однако …

anonymous
()
Ответ на: комментарий от X512

Кривые Безье, невыпуклые и самопересекающиеся кривые видеокарта рисовать не умеет насколько я знаю. Надо на CPU либо триангулировать, либо растеризовать в маску альфа-канала.

С OpenGL мне приходилось работать, но скорее всего не смогу поддержать диалог в вопросах, в которых разбираюсь не достаточно профессионально …

Исходя из своих «знаний» щитаю, что с OpenGL + шейдеры, … можно что угодно нарисовать …

anonymous
()

В частности интересно возможно ли нарисовать буфер в RAM на OpenGL

Можно, offscreen rendering в фреймбуфер, т.е создать фреймбуфер и в него рендерить. Или в текстуру что-то нарендерить. Доставать через glReadPixels если фреймбуфер и glGetTexImage если текстура. https://community.khronos.org/t/offscreen-rendering-vs-render-to-texture/63665 вот тут кое-что написано.

А можно наоборот, процессором что-то набросать в 2D массив в основной памяти, передать в видеокарту это, и потом что-то с этим дальше делать.

SZT ★★★★★
()
Последнее исправление: SZT (всего исправлений: 1)
Ответ на: комментарий от anonymous

Sorry за настырность

OpenGL видеокарты поддерживают, а некоторые и Vulkan.
Если мы чегой-то там мы не умеем, то это наши проблемы, а не видеокарты …

anonymous
()
Ответ на: комментарий от X512

Кривые Безье, невыпуклые и самопересекающиеся кривые видеокарта рисовать не умеет насколько я знаю.

Был же там OpenVG, но похоже не взлетел.

EXL ★★★★★
()
Ответ на: комментарий от X512

Если взять чисто шейдеры и выкинуть всё остальное что видеокарта может рисовать ровно то что ты запрограммируешь в шейдерах, короче что угодно, да хоть анимированную нят с дредами хлопающую глазами стоящую на мосту где позади ёлки стоят. Всё чисто на формулах и шуме перлина. Как в мультике будет современном.

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)
Ответ на: комментарий от LINUX-ORG-RU

Если взять чисто шейдеры и выкинуть всё остальное что видеокарта может рисовать ровно то что ты запрограммируешь в шейдерах

Алгоритмы триангуляции и работы с кривыми плохо параллелизуются. На CPU они будут работать быстрее.

X512 ★★★★★
() автор топика
Ответ на: комментарий от X512

Алгоритмы триангуляции и работы с кривыми плохо параллелизуются. На CPU они будут работать быстрее.

Признавайтесь, что вы там задумали?

anonymous
()
Ответ на: комментарий от X512

Алгоритмы триангуляции и работы с кривыми плохо параллелизуются. На CPU они будут работать быстрее.

Признавайтесь, что вы там задумали?
Когда-то разработал редактор на основе Notepad++.
Исходники Notepad++ не использовал, а вот *.xml из него утащил.
Но с xml работая простая но очень муторная.
Пишем API в class, которое предосталяет всякий функционал.
Все муторно, просто и долго …
Сегодня для *.xml сделал объектную базу …
Код для работы с ней разработаю чуть позже.

В чем профит?
Было 800KB исходников, которые будут заменены на 4KB с тем же функционалом …

Вообщем

Не скучно
anonymous
()
Ответ на: комментарий от X512

Реализацию аппаратного ускорения в Haiku на основе Mesa3D.

Спасибо!
Начну разработку GUI на основе объектно-ориентированной метадата базы /что удивительно, похоже ни кто и не понимает о чем речь, хотя само название же ведь о многом говорит/, так что еще пообщаемся …

Свое «незнание» буду подтягивать на реальной задаче …

anonymous
()
Ответ на: комментарий от anonymous

Когда-то разработал редактор на основе Notepad++. Исходники Notepad++ не использовал, а вот *.xml из него утащил.

И окна для настроек …
Теперь заменю все на свой GUI.
Редактор разрабатывался для того, чтобы оптимизировать работу с деревьями.
Редактируемый текст хранился в дереве, поэтому редактирование файла размером в 100MB ни чем не отличалось от файла размером 1MB.
Функциональность редактора конечно не дотягивала до Notepad++
Как сказал выше редактор разрабатывался лишь для оптимизации работы с деревьями.
Да и ныне вернусь к редактору не с целью разработать а-ля Notepad++ …

anonymous
()
Ответ на: комментарий от anonymous

Теперь заменю все на свой GUI.

Фишка GUI будем в том, что его можно будет использовать в любом проекте и он не будет привязан к компилятору …

Как и в целом разрабатываемое OLE
anonymous
()
Ответ на: комментарий от X512

На compute шейдере всё что угодно нарисуешь, прям как на проце.

anonymous
()
Ответ на: комментарий от X512

@X512 вас на форуме уважают.
Попросите корректоров, чтобы открыли раздел

Для Чайников

и пусть

мегают там светаиДотами
anonymous
()
Ответ на: комментарий от X512

даже если та отобрана у обычной RAM

А так можно?

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

EugeneBas ★★
()
12 октября 2021 г.

x512, кажется вы делаете что-то не то. Вы берете идеи из Линукс, которые были уместны 20 лет назад, и переносите в Haiku. Linux-это одна большая неувязка. но почему то во всем это бардаке, что зовется ядром, вы увидили только одну неразумность, когда видеодрайвер является частью ядра. Как раз это единственое логичная вещь в линукс, так как все драйвера находятся в

Device Drivers
и по причине того, что видеодрайвер, все же драйвер, его и запихали в ядро, ко всем драйверам. Но речь не об этом. Речь о том что ядро линукс не может быть примером для чего, кроме как примером того, что так делать не надо. Если хочешь написать ОС, то зайди в ядро Лиунукс, посмотри и сделай все иначе. Почему так? да потому что ядро было действительно создано гениальным человеком Линусом, но вся гениальность его была в том ,что он сумел присвоить себе труды тысячи людей, которые писали это ядро. Линус создал ядро но не написал. на какой-то стадии ядра, он уже перестал понимать что там происходит и теперь его главная и основная цель это не развития ядра, а то чтобы оно хоть как-то функционировала и приносила прибыль. Поэтому он принимает в ядро только те вещи, которые не смогут привести к каким-то коренным изменениям в его структуре. если коротоко, то ядро разбухает облепляясь всякой дичью, но не развивается. Да и те все люди кто писал бесплатно, теперь уже вряд ли что-то отададут хорошее ядру в виде кода, после того как осознали поступок Линуса. ядро окаменело в какой-то момент, или если проще то ядро мертво для 2021. но вы же умудряетесь черпать от туда вдохновение для Haiku. а что сами понять не можете что нужно для ОС сегодня? я тут слышал упреки в адрес будущих программистов, которых теперь будут готовить училища. многие заявляли что с выпускника техникума не может получиться программист. Господи, вы серьезно? это вы что ли программисты тут? которые присосались к кое как насаному много лет назад ядру и стараются затормозить все то на чем это ваше ядро выказало бы всю свою несостоятельность для сегодня. чем вы все тут лучше выпусников шараги? у вас же принцип как у слесаря иванова: работает не трогай! и что вы можете принести революционое? одни и теже тухлые идеи гуляют из одной ОС в другую! в ядре непросто всю конфиктует можду собой, там наружена внутренняя логика. вот ее то и надо дорабатывать и доводить до идеала.

anonymous
()
Ответ на: комментарий от anonymous

самая большая проблема даже не в том что ядро кривое, а в том что никто не хочет слышать что-то кроме лести и похвалы. так вы далеко не уедите. с такими товарищами, которые сидят на винде и кричать УМВР, УМВР! загинет и этот форум. да ты УМВР слезь с винды и поживи на линуксе с годик, что ты тогда запоешь? все это сообщество маленький макет нашего мира, состоящего из лизоблюдов, и похалимов с подпевалами. одни не хотят слышать ничего кроме лести, а другие говорят только то что хотят слышать.

anonymous
()
Ответ на: комментарий от anonymous

Да ты же шизик уровня «Эйнштейн украл идеи работая в патентном бюро и вообще теория относительности неправильная»

anonymous
()
Ответ на: комментарий от anonymous

ядро мертво для 2021

Настолько мертво, что полетело на Марс, а Microsoft внедрил в Windows сначала WSL, а потом WSL2.

загинет и этот форум

Вот уже 23 года «загинаемся».

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от izzholtik

они там в de требухе используют мега-древние версии opengl. в чуть менее древних такое не нужно

anonymous
()
Ответ на: комментарий от EXL

ты действительно веришь, что проект в миллиарды долларов подвергнуть такому риску, что опубликуют под управлением какой ОС запускаются космические аппараты? коды там не выкладывают случайно?

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от EXL

100% там Debian будет установлен. Только Величественный и надеждый Debian может быть удостоин такой чести, как полететь на Марс

anonymous
()
Ответ на: комментарий от anonymous

Извольте милейший, а чем Armbian плох? я считаю, что если уж миссия на марс, то тогда только Armbian в сборке от balbes150

anonymous
()
Ответ на: комментарий от anonymous

ты действительно веришь, что проект в миллиарды долларов подвергнуть такому риску, что опубликуют под управлением какой ОС запускаются космические аппараты? коды там не выкладывают случайно?

Ты не поверишь:

https://github.com/readme/featured/nasa-ingenuity-helicopter

EXL ★★★★★
()
Ответ на: комментарий от izzholtik

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

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

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

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

Я своим глазом видел диагональный тиринг (или нечто от него неотличимое) на нуво на 1030; кроме того, тем же глазом я видел диагональные артефакты при сбоях блоба на 1060.

izzholtik ★★★
()
Ответ на: комментарий от izzholtik

Значит на нвидия буфер кадра по диагонали рисует :D У меня двиди никогда не было в долгом пользовании. Промолчу. Мир полон чудес.

LINUX-ORG-RU ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.