- 1
- 2
Золотце
https://lj.rossia.org/users/sadkov/103320.html?nc=55-
Куча / Говнокод #24228
−2
OpenGL - говно опенсурсное
Попытался реализовать getPixel и putPixel на OpenGL, в результате получение одного пикселя занимает болшьшую часть времени выполнения программы. Другие люди тоже жалуются на тормознутость функций OpenGL, вроде glDrawPixels и glReadPixels
https://stackoverflow.com/questions/39821850/why-is-glreadpixels-so-slow-and-are-there-any-alternative
https://stackoverflow.com/questions/36534933/gldrawpixels-vs-textures-to-draw-a-2d-buffer-in-opengl
>glDrawPixels is known to be very slow
Зачем вообще нужно все это 3d ускорение? В DOS все было идеально:
((uint8_t*)(0xB8000))[y*320+x] = pixel
почему нельзя современным программам предоставить такой 0xB8000 адрес и пару регистров вывода? Зачем все эти ритуалы? И да, MMU и protected mode значительно замедляют доступ к памяти, посему современный DOS работал бы на порядок быстрей Windows/Linux. Протекция памяти оправдана только на этапе разработки программы, а для release билда ее лучше отключить, чтобы иметь прямой доступ к реальной памяти.
И я не одинок в негодовании:
https://stackoverflow.com/questions/39430404/drawing-pixels-in-opengl
>I'm using integrated GPU (Intel HD graphics 4000), as far as I know CPU and GPU share the same memory so why is it that I need to download? Why is it impossible to get a pointer?
Начинаю думать, что Unabomber был прав во всем - надо к чертям взорвать офисы мразотных бюрократов из Khronos Group.Запостил:
j123123,
05 Мая 2018
Follow us!
Особенно весело будет, когда в релиз билде обнаружат баг, через который (из-за отсутствия "протекции памяти") можно всю ОС поиметь и отформатировать жесткий диск
Вот в DOS было заебись
mov туда
mov сюда
Спасибо, но я лучше uefi shell какой-нибудь возьму -- уже 64 бита, но контроль над железом и памятью (замапана 1:1) ещё остаётся.
З.Ы. Там в консольке есть команды для сранья в io порты (!) и няшный хекс редактор для памяти и диска.
Хуита.
Он ntfs поддержтвает?
ЗЫ. На компах с биосом не будит работать.
Х.з., я не искал, но r/o драйвер вроде где-то был. Для FreeDOS есть более полноценный?
> На компах с биосом
Ты когда последний раз видел комп с настоящим бивисом, а не Compatibility Support Module от UEFI? Только честно.
> не будит работать
Через жопу, но будет. Есть специальная реализация UEFI которая грузится не с голого железа, а через BIOS.
Когда-то давно у меня был загрузочный диск с разными утилитками, на нем был урезаный линупс, дос и ещё дохуища всего, и среди этого дохуища были разные файл манагеры для ntfs. (можно было ломать венду:))
> когда последний раз видел комп с настоящим бивисом
Сегодня за ним сидел на лабе. И во всяких Залупосрансках, в говноинститутах и говношколах стоят допотопные компы, котороые помнят еще шиндос98 (наверное).
Чот я щас подумал: фридос риально не нужен, а для старых прог есть досбокс.
Из досбокса биос не перепрошить
У меня тоже. ASRock поди?
З.Ы. Мне там ещё обзор материнки нравится прямо из setup'а — на фотке показано что в какие слоты воткнуто.
ЗЫ. Интересно, есть ли прошивалки под KolibriOS или MenuetOS?
Ебать как интересно)))
Лучше BareMetal OS возьми.
А еще есть TempleOS, написанная шизиком-программистом.
> The software is a x86-64 bit, multi-tasking, multi-cored, public domain, open source, ring-0-only, single address space, non-networked, PC operating system for recreational programming. The operating system was designed to be the Third Temple according to Davis and uses an interface similar to a mixture of DOS and Turbo C.
Да ладно... Low-level хаки и бутылочных котов можно unsafe'ом обмазать (всё лучше, чем вся прога целиком в unsafe как в няшной), ГЦ -- не обязательный признак безопасного языка, а остальному коду тупо похуй.
Безопастный это где нет болтающегося укойзателя?
Приведи пример ЯПа с ГЦ и с болтающимся указателем (unsafe хаки не рассматнриваем)
> в DOS было заебись
Что за язык такой — DOS?
* Boeing 787
* Некоторые PostScript-принтеры.
:))))))))))))))
Там просто слово-в-слово написано
OpenGL methods are used to manage the rendering pipeline. In its nature, while the graphics card is showing image to the viewer, computations of the next frame are being done. When you call glReadPixels; graphics card wait for the current frame to be done
зы: писал тут длинный гневный псот про то что в досе не все так было хорошо как он тут нам изобразил: потому что планары, синхронизация с обратным ходом луча и пр, но пост убился
это высер sadkov а не топикстартера, так что вся хуита про прямой доступ к памяти это к нему вопрос, ок
Про read то понятно. Из-за синхронности он просто не может не убивать пирфоманс (асинхронная выгрузка через PBO не тормозит, к слову).
А вот draw по идее можно было бы оптимизнуть -- оно же не против шерсти. Хотя может быть просто не хотят неявно аллоцировать буфера и держать их неопределённое время, тем более когда есть альтернатива с PBO.
http://a2ch.ru/i/c77ebc0d6755486cff45c5e237b4d502