1. Куча / Говнокод #24228

    −2

    1. 1
    2. 2
    Золотце
    https://lj.rossia.org/users/sadkov/103320.html?nc=55

    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

    Комментарии (48) RSS

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

      Особенно весело будет, когда в релиз билде обнаружат баг, через который (из-за отсутствия "протекции памяти") можно всю ОС поиметь и отформатировать жесткий диск
      Ответить
      • Значит плохо разрабатывал. Юзай безопасные языки.
        Ответить
        • безопасные языки тормозят.
          Вот в DOS было заебись
          mov туда
          mov сюда
          Ответить
          • Есть же фридос. Он ещё жив? Кто знает, с ним можно нормально житть?
            Ответить
            • Он же 16 битный для совместимости?

              Спасибо, но я лучше uefi shell какой-нибудь возьму -- уже 64 бита, но контроль над железом и памятью (замапана 1:1) ещё остаётся.

              З.Ы. Там в консольке есть команды для сранья в io порты (!) и няшный хекс редактор для памяти и диска.
              Ответить
              • Лол, почему-то не могу зайти на сайт фридоса. По ссылке с Янжекса на главную ещё могу зайти и всё. Даже с прокси не открывается.
                Хуита.
                Ответить
              • >uefi shell
                Он ntfs поддержтвает?

                ЗЫ. На компах с биосом не будит работать.
                Ответить
                • > ntfs
                  Х.з., я не искал, но r/o драйвер вроде где-то был. Для FreeDOS есть более полноценный?

                  > На компах с биосом
                  Ты когда последний раз видел комп с настоящим бивисом, а не Compatibility Support Module от UEFI? Только честно.

                  > не будит работать
                  Через жопу, но будет. Есть специальная реализация UEFI которая грузится не с голого железа, а через BIOS.
                  Ответить
                  • > Для FreeDOS есть более полноценный?
                    Когда-то давно у меня был загрузочный диск с разными утилитками, на нем был урезаный линупс, дос и ещё дохуища всего, и среди этого дохуища были разные файл манагеры для ntfs. (можно было ломать венду:))

                    > когда последний раз видел комп с настоящим бивисом
                    Сегодня за ним сидел на лабе. И во всяких Залупосрансках, в говноинститутах и говношколах стоят допотопные компы, котороые помнят еще шиндос98 (наверное).

                    Чот я щас подумал: фридос риально не нужен, а для старых прог есть досбокс.
                    Ответить
                    • >Чот я щас подумал: фридос риально не нужен, а для старых прог есть досбокс.

                      Из досбокса биос не перепрошить
                      Ответить
                      • А прошивалку под винду производитель не осилил?
                        Ответить
                        • Винду еще куда-то ставить надо, а загрузочную флешку с фридосом сделать значительно проще. К тому же ставить винду только чтобы перепрошить биос это как-то тупо
                          Ответить
                          • Мне однажды материнка попадалась, которая просто сама читает обновление с флешки. И не надо никаких фридосов, линуксов, виндов… Самая кошерная схема, имхо. Почему все так не делают — х.з.
                            Ответить
                            • Хм, у меня производитель пошёл ещё дальше - материнка умеет через интернет обновляться. Не автоматически, правда.
                              Ответить
                              • > умеет через интернет обновляться
                                У меня тоже. ASRock поди?

                                З.Ы. Мне там ещё обзор материнки нравится прямо из setup'а — на фотке показано что в какие слоты воткнуто.
                                Ответить
                            • Будет очень интересно, когда найдётся уязвимость, связанная с чтением обновления.
                              Ответить
                              • Дык прошивки давным-давно подпись проверяют перед обновлением. Не думаю, что эта схема опаснее чем получение файла с апдейтом от винды/доса.
                                Ответить
                            • примерно 10 лет уже как asusы так делают
                              Ответить
                          • Прыщебляди должны страдать.
                            Ответить
                          • Кроме фридоса полно других небольших осей. Та же TinyCore — линух ~ 16 метров, и это ещё с гуями. Ещё есть урезанные виндосы.

                            ЗЫ. Интересно, есть ли прошивалки под KolibriOS или MenuetOS?
                            Ответить
              • > Спасибо, но я лучше uefi shell какой-нибудь возьму -- уже 64 бита, но контроль над железом и памятью (замапана 1:1) ещё остаётся.

                Лучше 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?
            Ответить
            • Ну так клован же привел пример 13h режима, противопоставив его OpenGL, ну вот я и ответил в его духе
              Ответить
      • Зачем так сложно. Можно начать с поиска утечек памяти под VxWorks.
        Ответить
        • VxWorks я встречал пока только в китайских LTE модемах
          Ответить
          • тем не менее VxWorks работает на оборудовании кучи заводов (это я сам видел и даже однажды трогал), вроде как летает по орбите - поэтому баги или тем более дырки там пиздец какие дорогие
            Ответить
            • *Зонды Spirit, Opportunity и Curiosity,
              * Boeing 787
              * Некоторые PostScript-принтеры.
              :))))))))))))))
              Ответить
    • Кстати, а правда, почему draw pixels такой медленный? Просто из-за того, что он никому не нужен и всем лень его оптимизировать (выразить через те же текстуры, чтобы поперёк пайплайна не лезть, к примеру)?
      Ответить
      • Скажи честно, ты догадался сам или по ссылке пошел?
        Там просто слово-в-слово написано

        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.
          Ответить
    • ванишд
      Ответить
    • а он тролль или дурак?
      Ответить
    • OpenGL -> Direct3D
      Ответить
      • Direct3D разве даёт быстрый доступ к фреймбуферу?
        Ответить
    • OpenGL — Open Gay Lips
      Ответить

    Добавить комментарий