1. JavaScript / Говнокод #14327

    +167

    1. 1
    2. 2
    gl.drawArrays(gl.QUADS, 0, 4);
    // WebGL рисует черный экран с четырьмя точками.

    bormand vs WebGL. Акт второй.

    Как оказалось, в OpenGL ES выпилили GL_QUADS и GL_POLYGON.
    Но т.к. в js несуществующее поле это null, а null это 0, а 0 это GL_POINTS, то рисуются 4 точки ;)

    Запостил: bormand, 07 Января 2014

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

    • индустриальная мощь js'а!
      Ответить
      • Не строгая динамическая типизация не нужна
        Ответить
    • > в OpenGL ES выпилили GL_QUADS и GL_POLYGON.
      Правильно сделали. Выпилили устаревшее говно. Треугольники только нужны. На крайний случай можно оставить точки и линии, но и то не сильно нужно
      Ответить
      • А они и в старом не особо нужны были. GL_TRIANGLE_FAN оба этих режима полностью эмулировал, правда в wireframe режиме рисовал лишние линии. Ну а поскольку wireframe выпилили, то и режимы стали ненужными.

        > но и то не сильно нужно
        Линии не трожь! Заебешься же потом их треугольниками рисовать ;) А из точек, емнип, делаются отличные и очень дешевые системы частиц.
        Ответить
        • куча видях кругом, что не умеют в точки и линии. там драверописатели треугольниками все эмулируют. ты просто не в курсе. иной раз оно гибче и быстрее получается через трианглы самому
          Ответить
        • вирефрейм (линии) больше для отладки нужны. такчто нечего на них транзиторы в видяхе тратить. а точки трианглами тоже просто эмулировать, так что точки тоже редко где ускоряют
          Ответить
          • кстати, а в готика 1 и 2 дождь рисуется линиями
            а бугорки когда дождинка разбивается о землю - точками
            Ответить
      • А чем заливка треугольника отличается от заливки любого выпуклого многоугольника?
        Ответить
        • Тем что придется отдельно многоугольники триангулировать. В результате в батчах для гпу будет не оптимально обстрипфанена модель (сжата не оптимальным образом), что отрицательно скажется на троугхпуте. В то время как все гейдевки борются за каждый триангл в секунду, то вводить не оптимальный способ записи батчей в стандарт, который придется эмулировать в драйверах, получая тормоза и геморой - это питушня.
          Ответить
          • я всегда считал, что заливать прямоугольники быстрее
            Ответить
            • Если они стоят вертикально или горизонтально - да, всяко :)

              Трабла тут в том, что из прямоугольников не сложить произвольную фигуру.
              Ответить
              • > из прямоугольников не сложить произвольную фигуру
                Ну если это не пиксели :)
                Ответить
            • ты путаешь аппаратную и программную поддержку. тут под многоугольником имеются введу не обязательно прямоугольники.
              так вот на треугольники хардвар саппорт есть, а на многоугольники может когда-то и была хардвар поддержка в каких-нибудь редких opengl френдли картах, то сейчас уже не встретишь такую карту.
              Ответить
          • > Тем что придется отдельно многоугольники триангулировать.
            Нахуй не надо. Просто надо отказаться от стандартной питушни "разделим треугольник на два, долго сортируя его вершины и разбирая джва случая - промежуточна вершина справа от грани или промежуточная вершина слева от грани".
            Ответить
            • Это только в софтрендере. Видяхе могут прилетать произвольные треугольники, а не только с одной параллельной гранью сканлайну. На них полигоны и бьют (триангулируют).
              Ответить
              • А что софтрендер - АЛГОРИТМ он везде одинаковый, хоть он в видяхе написан, хоть в процессоре, просто в видяхе рахитектуру закостылили.
                Ответить
                • Я щас ляпну не по теме. Почему q2 на софтваре и на 3d выглядит по-разному?
                  Ответить
                  • и на чём, простите?
                    Потому что кармак не осилил цветное освещение, а видяхи не осилили чтобы всё плавало под водой и ещё пейсатели опенглорендера не осилили ещё дохрена чего, вот статья по теме: https://www.quaddicted.com/engines/software_vs_glquake
                    Ответить
                    • >и на чём, простите?
                      В смысле? На какой карте? На любой, даже 98 года.

                      Это про ку1, он у меня на ускорителе вообще не шел, а я про ку2, там реально разная цветовая гамма.
                      Ответить
                      • http://www.youtube.com/watch?v=Lp7pkxs5ozU ~1:30 там еще плохо видно, на q2dm1 лучше.
                        Ответить
                      • > В смысле?
                        Твой пост:

                        > Почему q2 на софтваре и на 3d выглядит по-разному?

                        Ты понял что блять написал?

                        В ку2 кармак ниасилил цветное освещение в софтваре, то ли цветов не хватило, то ли ещё что, а в ускоренных режимах осилил.
                        Ответить
                        • >Ты понял что блять написал?
                          На 3д ускорителе, не приёбуйся. Бля, там гамма абсолютно другая - на софтваре q2dm1 зеленый, а на 3d - желтый.
                          Ответить
                • Ну как ты на железе будешь работать с произвольным числом вершин? Где ты собираешься их хранить? Тратить лишние транзисторы на блок растеризации, чтобы он мог работать с 20-угольниками? Что делать, если прислали 21-угольник? Падать? Переходить на бекапный алгоритм и пытаться рисовать кусками?

                  Как отделять полигоны друг от друга в батче? Делать какой-то разделитель? Передавать длину? Делать 100500 батчей по одному полигону вместо одного стрипа? У тебя меш будет весить больше, чем если его составлять из тупых треугольников :)

                  А бить модель на треугольники, в большинстве случаев, надо один раз - при экспорте модели.

                  Короче, имхо, оно того не стоит.
                  Ответить
                  • Как я собрался это делать?
                    Хм, как же процессор это делает?
                    Ответить
                    • Вопросы риторические? А мой вопрос риторичен?
                      Ответить
                    • Ну обычный процессор это как бы довольно сложное и универсальное устройство. И он как бы немного медленный и последовательный.

                      Что-то мне кажется, что на видюхе все-таки стоит какой-то совсем кастрированный аппаратный модуль (ALU'шки, счетчики, регистры и т.п.) для разбиения треугольников на пиксели + железный интерполятор varying переменных по площади этого треугольника. Ну не тратят же они на это ресурсы модулей, которые занимаются пиксельными шейдерами? Эти пиксельные шейдеры на старых видюхах были довольно убогими, и до совсем недавнего времени даже циклы не могли крутить. А треугольники же как-то рисовали ;)

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

                      Но я могу ошибаться, т.к. архитектуру видюх не изучал.
                      Ответить
                      • Хотя х.з. очень вероятно, что Тарас и прав, и на новых видюшках все это давным-давно считается теми же модулями, что и шейдеры.
                        Ответить
                        • >в видюшках все это давным-давно считается теми же модулями
                          Ну вот x86 взять. Снаружи CISC, типа удобство для программера (хотя с таким набором как сейчас и в разных процах совершенно разные наборы комманд, оптимизация кода приводит к написанию N веток).

                          Но внутри ведь оно RISC, то есть бьётся декодером на мелкие операции (МОПы).
                          Декодер инструкций конечно занимает довольно много места на кристале и электичества тоже. Но это получается как фасад, более удобный для человека.

                          И одна инструкция это как батч, а внутри она может разбиваться на сотни МОПов (см. строковые фичи из SSE4.2)

                          >>считается теми же модулями
                          Вот MMX,SSE,AVX и x86 целочисленные инструкции, они исполняются на одних и тех же вычислительных блоках.
                          Операции с памятью (неважно какой набор) используют одни и те же LOAD/STORE, дробные - тоже.
                          Только SSE,AVX - это примитивные своего рода батчи. Идея та же.
                          Block Reuse короче.
                          Кстати борманду тоже +1.
                          Ответить
                    • Ну вот кстати, полистал немного про архитектуру нвидиевских видюх. Там получается, что читать из памяти довольно невыгодно, значит придется на время заливки треугольника хранить кординаты вершин и пачку атрибутов прямо в регистрах SM'a. А их естественно не бесконечно много. Треугольник тут дает гарантию, что он всяко влезет, если число атрибутов в пределах указанного производителем видяхи.

                      Плюс там код исполняется только пачками (нвидия зовет их варпами) по 32 потока. И если я правильно понял, они всегда идут синхронно. Т.е. крутить в пределах одного варпа в одном потоке цикл до 2 а во втором до 3 не выйдет. Тот, в котором 2 итерации должен тупо пропускать инструкции и ждать, пока второй делает третью...

                      Вот в таких условиях я бы не рискнул мутить заливку произвольного многоугольника...
                      Ответить
                      • Да, все так с Nvidia. А теперь представьте как нужно на CUDA данные компоновать...
                        Ответить
                        • Костыли убогой архитектуры.
                          Ответить
                          • А пропогандируется как будущее.

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

                            Ну и кому интересно (в частности Борманду) почитайте о NVidia GRID - занимательно, но нужно знать буржуйский
                            Ответить
                            • > но нужно знать буржуйский
                              No problem :)

                              > почитайте о NVidia GRID
                              Да мне это юзать негде, разве что в общем плане посмотреть, для развития.
                              Ответить
                              • Да тыж так скорого гейдевкой станешь.
                                Ответить
                                • > Да тыж так скорого гейдевкой станешь.
                                  А я когда-то хотел сделать свой игровой движок на крестах. Но что-то меня вовремя остановило...

                                  А нвидиевские и атишные GPU же можно не только для игрух юзать.
                                  Ответить
                          • > Костыли убогой архитектуры.
                            Просто 32 полноценных треда будут жрать больше, чем 32 вот таких вот слепленных в кучу. И транзисторов будет на порядок больше, а там их уже где-то 2.5миллиарда.

                            А для обработки картинок, физики, да всяких FFT слепленные треды, имхо, вполне подходят.

                            Ну и эта синхронность не только недостаток. Треды в пределах одного варпа могут общаться друг с другом без синхронизации и ожиданий.
                            Ответить
                          • Скептицизм в этом вопросе меня удивляет.

                            RISC и её последователи тем-то и хороши, что они могут шустро делать очень много мелких и простых операций.

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

                            И в лего, и в проектировании софта, и в строительстве домов и в геймдеве тоже.

                            Я бы назвал многоугольники графическим сахаром.
                            PS. +1 LispGovno по треду.
                            Ответить
                            • > Я бы назвал многоугольники графическим сахаром.
                              Тем более они не так часто и нужны. Большинство интересных и красивых моделек в играх все-таки не квадратные кирпичи, и не додекаэдры, а нечто, имеющее кучу криволинейных форм, которые удобней всего приближать как раз большим числом треугольников.
                              Ответить
                      • >Плюс там код исполняется только пачками (нвидия зовет их варпами) по 32 потока. И если я правильно понял, они всегда идут синхронно.
                        Это ты открыл для себя SIMD? :)
                        Ответить
                        • SIMD — это когда одна инструкция обрабатывает сразу массив (сингл инстракшн — мани дейта). А когда несколько инструкций обрабатываются параллельно, называется по-другому. VLIW, например.
                          Ответить
    • В js несуществующее поле это undefined, а +undefined это NaN.
      Ответить
      • Хм, а почему тогда функция не крашится... Походу они тупо посчитали андефайнед нулем уже в сишной части кода...
        Ответить
        • С WebGL не работал, но могу предположить, что выполняется преобразование к Int32 или UInt32.
          undefined | 0 // => 0
          undefined >>> 0 // => 0
          Ответить
          • ещё было undefined == null, может где-то этим воспользовались, только я в это не верю
            Ответить
    • Почему http://govnokod.ru/14332 нет на глагне?
      Ответить
    • > Но т.к. в js несуществующее поле это null,
      Разве не undefined?
      Ответить
      • > Разве не undefined?
        undefined конечно. Выше уже об этом отписали.
        Ответить

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