Лучше бы MS написали сборщик мусора для C++ и вошли бы в комитет по стандартизации C++ и включили бы этот сборщик в стандарт C++ Тогда бы плюсовый парсер выдавал бы >61Mb/s
тогда То на ТО и выходит по-лбасе, но никак не медленней))
Погоди, а разве невозможно запустить следующие еще неотработанные фрагменты?
Например у меня 1000 ядер и около 500000 фрагментов, зачем GPU будет простаивать если все фрагменты могут работать независимо друг от друга? Фрагменты то эти соответствуют пикселям на экране. Все они — видимые — уже прошли Z-Test. Это вся рабочая группа с фрагментами должна ждать выполнения всей рабочей группы с вершинами, а затем должна ждать растеризацию и Z-Test и всю промежутоную хрень. Количества ядер на все пиксели ни в одной суперкрутой видюхе по-любасе не хватает, их всего то от силы 1000-5000. А пикселей — 1920x1080, а бывает и больше.
Фрагменты можно рассматривать как очередь задач, которую мы скармливаем пулу потоков.
Нельзя ли написать реализацию для нескольких ip адресов в библиотеке libfcgi?
Соответственно, надо найти место где парсится адрес от порта в int FCGX_OpenSocket(const char* path, int) и наверняка адрес пишется в какую то переменную char*, вместо неё завести переменную set<char*>, далее запустить компиляцию libfcgi, далее идти по местам ошибок компиляции и действовать по смыслу, скорее всего заменять проверку на проверку в цикле.
Сокеты Беркли для tcp позволяют узнать адрес инициатора у accept-сокета в аргументе cliaddr
для udp — используя функцию recvfrom. По классике в сокетах Беркли recvfrom нет, Но она по-моему на всех платформах реализована, в линуха уж точно есть. И уж наверняка юзается в libfcgi. Они правда могли биндить и при биндинге указать допустимый адрес.
Короче полюбасе надо бы такую штуку провернуть, заодно покурив мануалы по сокетам.
Погоди, разве дискард не просто-напросто прерывает работу текущего шейдера, а следовательно невидимые фрагменты выполняются только до проверки if(d2>r2), далее никаких вычислений и пиксель просто не перекрашивается и всё? Следовательно, фрагмент с discard заканчивает свою работу быстрее, чем фрагмент не попадающий в блок с дискардом.
Круть, я пока код шейдеров не посмотрел, не врубился как ты сделал вычисление расстояния от центра.
Спс за подсказку!
А подскажи, как можно на этой же версии шейдеров определять, какой фрагмент либо лежит на ребре треугольника, либо насколько удалён от ребра треугольника? Ведь инфы о соседних вершинах старые шейдеры по имени Верт и Фраг не знают…
Неужели хардкорно передавать в шейдер с помощью uniform координаты остальных двух вершин?
Похоже я сам ответил на свой вопрос…
Это я думаю как может быть реализован toon shader на старом пайплайне просто.
Поясню про toon shader — я имею в виду техника, раскрашивающая ребра и все около этого, можно и углы между треугольником и направлением взора считать и соответственно раскрашивать силуэт для замкнутых мешей.
Кто это «мы» видели?
И причем тут языки программирования?
Новый язык нафик не нужен, потому что есть C++, Java, их и так 100500. что мешает хотя бы C использовать вместо непонятного и ущербного cmake 2.8? Нахрена изучать новую матчасть, нахрена заставлять людей мучиться и себя тоже?
Лень арифметику указателей имплементировать?
Возьми стандарт ECMA Script, например готовый QtScript из того же Qt, там уже все реализовано, вставь в свой CMake и нечего какие то непонятные языки-велосипеды изобретать.
Если я бы был инвестором — послал бы нахрен этих изобретателей cmake 2.8, но Cmake ведь бесплатный.
Нашел книгу.
Прочитал тот момент когда чувак сравнивал пиксели, всмысле пытался распознать HTML элементы по пикселям ( цвет RGB неважен). Ну так тестовая компонента должна хорошо распознавать образы, если она будет криво распознавать, то тест будет провален.
К тому же чуваки сравнивали получившуюся картинку с уже имеющейся (от предыдущих версий браузеров или браузеров других производителей)
А вот если такой картинки нет? 2 млн пикселей раскрашивать вручную в граф редакторе как то не улыбается.
К тому же тест только отловит сам факт бага, без указания на причину.
Есть конечно альтернативная идея:
написать своё GAPI-заглушку, но вот что поместить внутри не совсем понятно. Искусственный интеллект? Жесткую проверку?
Такой тест будет только проверять наличие того, сего, пятого, десятого и порядок вызова их. Может быть сможет отлавливать какие то известные графические артефакты-баги.
Но идея с чтением пикселей полезна:
Например, можно сравнивать рендеринг старой и новой версии движка при тех же исходных данных. Ну скажем, захотели мы портировать нашу игруху скажем на планшет.)
вот-вот и я про то-же.
И вообще попиксельный тест хорошо ляжет, если мы например производим портирование движка на другую версию графического пайплайна, например переходим с DirectX на OpenGL или со старого OpenGL на OpenGL с новым пайплайном. А иначе нам и эти точки брать неоткуда, как мы их будем генерить если ничего нету изначально, сами вручную 2 млн. точек в графическом редакторе рисовать чтоли?
Вобщем геммора с этими тестами на рендеринг много, кроме одного полезного нюанса:
Можно проверять правильность рендеринга при переходе на другой GAPI или на другой пайплайн.
Поменяется способ рендеринга, производительность, кол-во оперативной и видеопамяти. Т.е. по другому распределятся ресурсы. Возможно ( при других обстоятельствах, не пр работе с VBO, например при настройке точности Z- bufferа и передней и задней плоскости отсечения) могут вылезти графические артефакты.
Вот и вопрос: как проверить что артефактов не будет и будут правильно распределяться ресурсы и т.д.?
Есть вещи, которые невозможно протестировать вообще никакими автоматизированными тестами.
Например, реализация современных технологий рендеринга трехмерной графики.
Скажем, реализация Deffered Lightning — отложенного освещения на OpenGL. И как тут писать автоматизированный тест?
У компоненты, производящей рендеринг нету интерфейса, с помощью которого можно узнать «состояние всего».
Как мы проверим автоматизированным тестом, загрузили ли мы текстуры в VBO или биндим их из оперативки? Ведь сама картинка даже не поменяется. Или как проверить используем ли мы массив треугольников с вершинами, массив нормалей и массив текстурных координат Или мы используем массив вершин, массив нормалей, массив текстурных координат и массив треуголников с индексами на предыдущие массивы?
Спасибо! Хорошее пособие!
Мне как раз дали тестовое задание — трехмерный рендеринг под Windows без использования внешних зависимостей.
Qt не канает потому что не засунуть исходники QWidget и QGLWidget в проект (там слишком дохрена всего), MFC тоже не канает, потому что приложение может собираться не только cl.exe, но и migw32.exe, а значит вместо *.lib будет *.o и формат другой совсем. MFC то рассчитана на сборку студией по крайней мере линковка с ихними либками.
Наверно, потому что у тебя OpenCL собрана поверх CUDA, возможно на других платформах твоя OpenCL софтина будет даже быстрее. (если конечно будет с чем сравнивать)
Расскажи лучше или приведи пример пиксельного шейдера, который читает из Z bufferа и чего то делает с этим значением — например сравнивает с чем то. Как передать какую либо карту(текстуру) в (любой) шейдер, узнать ее размер и всю ее прочитать в цикле (например просуммировать все значения). Как в пиксельном/вертексном шейдере узнать его номер вызова, ну то есть первый раз, второй, третий и т.д. Ведь известно что вершинный шейдер вызывается столько раз сколько «кол-во треугольников»*3, а фрагментный столько раз, сколько для каждого треугольника получается фрагментов (то есть пикселей на экране монитора) в результате растеризации треугольников после трансформации. Так вот как узнать текущее число вызовов какого либо шейдера, чтобы в последствии использовать это число в вычислениях. Короче, как счетчик сделать?
я нашел про делеты и ньюшки со скобками и без. Есть две стратегии и в обоих компилятор так компилирует, что размер массива запоминается. Первый подход — с переаллоцированием для дополнительной переменной где хранится размер, второй подход — отдельный ассоциантивный массив с указателями в кач-ве ключа и размером в кач-ве значения. Эти механизмы реализуются на уровне компиляторов. www.parashift.com/c++-faq-lite/num-elems-in-new-array.html
поэтому компилятор знает сколько деструкторов вызывать.
Поэтому неопределенное поведение при использовании неправильного delete
Ок, а как еще по другому можно? Естественно если указать num меньше чем реальная длина строки src, то нуля в конце dest мы не получим. А с какой стати функция его должна ставить и самое главное куда? При условии что программист может забыть выделить под dest место равное длина строки + длина символа завершения.
strcpy_s тоже может повредить кучу, если недостаточно выделить места под dest
strcpy_s автоматически определяет размер статического массива, если передается статический массив в качестве назначения, то есть она имеет соответствующую специализацию шаблона. Написано что всегда ставит null в конце строки, значит в dst копируется из src sizeof(dst)-1 элементов и затем в dst добавляется в конце null.
Круто.
А вот интересно, что будет если скормить strcpy_s вот это:
char dst[1]; // Статический массив из одного элемента — не строка ибо не так :char dst[] = «a»;!!!
strcpy_s(dst, «A»);
В dst будет только null terminated символ?
Ну в принципе безопасно, но тоже не однозначно.
Ну лан пофиг strcpy и иже с ними пришли из древнего C.
Для наибольшей безопасности, если она так нужна, пользуйтесь string'ом и его перегруженными операторами, insert'ом, replace'ом и т.д.
Я вообще не понимаю, почему бы Микрософту не сделать свой API совместимым с STL.
Наверно потому, что нужна поддержка C и таких программистов очень много. Сейчас кстати C и C++ развиваются разными путями. Например в C есть ключевое слово restrict. В C++ его нет и не предвидится.
Страуструп здесь маху дал. Надо бы было поддержку C11 включить в стандарт C++11 или хотя бы в C++14 ну или в C++17
Иначе мы получим несовместимость, некроссплатформенность, кучу геммора при попытке скомпилить современный Си код вместе с C++ кодом в одной единице трансляции и два разных языка, которые в принципе могли бы быть одним единственным, как было в 80 — 90 годах
Жесть, одним словом (((
OpenCL полностью кроссплатформенная, а CUDA только на NVIDIA продуктах будет работать. Вот и вся разница. Иногда OpenCL может работать поверх CUDA, если хотим GPGPU, а графический процессор не поддерживает OpenCL, но поддерживает CUDA. Зато на OpenCL один раз написал хитрые алгоритмы и не паришься
Значит, особенности архитектуры?
Инженерам из NVidia и AMD конечно виднее.
Но по-любому discard скорости не уменьшит, просто будет простой части вычислительной мощности и всё.
Погоди, а разве невозможно запустить следующие еще неотработанные фрагменты?
Например у меня 1000 ядер и около 500000 фрагментов, зачем GPU будет простаивать если все фрагменты могут работать независимо друг от друга? Фрагменты то эти соответствуют пикселям на экране. Все они — видимые — уже прошли Z-Test. Это вся рабочая группа с фрагментами должна ждать выполнения всей рабочей группы с вершинами, а затем должна ждать растеризацию и Z-Test и всю промежутоную хрень. Количества ядер на все пиксели ни в одной суперкрутой видюхе по-любасе не хватает, их всего то от силы 1000-5000. А пикселей — 1920x1080, а бывает и больше.
Фрагменты можно рассматривать как очередь задач, которую мы скармливаем пулу потоков.
Соответственно, надо найти место где парсится адрес от порта в int FCGX_OpenSocket(const char* path, int) и наверняка адрес пишется в какую то переменную char*, вместо неё завести переменную set<char*>, далее запустить компиляцию libfcgi, далее идти по местам ошибок компиляции и действовать по смыслу, скорее всего заменять проверку на проверку в цикле.
Сокеты Беркли для tcp позволяют узнать адрес инициатора у accept-сокета в аргументе cliaddr
для udp — используя функцию recvfrom. По классике в сокетах Беркли recvfrom нет, Но она по-моему на всех платформах реализована, в линуха уж точно есть. И уж наверняка юзается в libfcgi. Они правда могли биндить и при биндинге указать допустимый адрес.
Короче полюбасе надо бы такую штуку провернуть, заодно покурив мануалы по сокетам.
Спс за подсказку!
А подскажи, как можно на этой же версии шейдеров определять, какой фрагмент либо лежит на ребре треугольника, либо насколько удалён от ребра треугольника? Ведь инфы о соседних вершинах старые шейдеры по имени Верт и Фраг не знают…
Неужели хардкорно передавать в шейдер с помощью uniform координаты остальных двух вершин?
Похоже я сам ответил на свой вопрос…
Это я думаю как может быть реализован toon shader на старом пайплайне просто.
Поясню про toon shader — я имею в виду техника, раскрашивающая ребра и все около этого, можно и углы между треугольником и направлением взора считать и соответственно раскрашивать силуэт для замкнутых мешей.
И причем тут языки программирования?
Новый язык нафик не нужен, потому что есть C++, Java, их и так 100500. что мешает хотя бы C использовать вместо непонятного и ущербного cmake 2.8? Нахрена изучать новую матчасть, нахрена заставлять людей мучиться и себя тоже?
Лень арифметику указателей имплементировать?
Возьми стандарт ECMA Script, например готовый QtScript из того же Qt, там уже все реализовано, вставь в свой CMake и нечего какие то непонятные языки-велосипеды изобретать.
Если я бы был инвестором — послал бы нахрен этих изобретателей cmake 2.8, но Cmake ведь бесплатный.
Вот и вопрос: как проверить что артефактов не будет и будут правильно распределяться ресурсы и т.д.?
Например, реализация современных технологий рендеринга трехмерной графики.
Скажем, реализация Deffered Lightning — отложенного освещения на OpenGL. И как тут писать автоматизированный тест?
У компоненты, производящей рендеринг нету интерфейса, с помощью которого можно узнать «состояние всего».
Как мы проверим автоматизированным тестом, загрузили ли мы текстуры в VBO или биндим их из оперативки? Ведь сама картинка даже не поменяется. Или как проверить используем ли мы массив треугольников с вершинами, массив нормалей и массив текстурных координат Или мы используем массив вершин, массив нормалей, массив текстурных координат и массив треуголников с индексами на предыдущие массивы?
Мне как раз дали тестовое задание — трехмерный рендеринг под Windows без использования внешних зависимостей.
Qt не канает потому что не засунуть исходники QWidget и QGLWidget в проект (там слишком дохрена всего), MFC тоже не канает, потому что приложение может собираться не только cl.exe, но и migw32.exe, а значит вместо *.lib будет *.o и формат другой совсем. MFC то рассчитана на сборку студией по крайней мере линковка с ихними либками.
поэтому компилятор знает сколько деструкторов вызывать.
Поэтому неопределенное поведение при использовании неправильного delete
strcpy_s тоже может повредить кучу, если недостаточно выделить места под dest
strcpy_s автоматически определяет размер статического массива, если передается статический массив в качестве назначения, то есть она имеет соответствующую специализацию шаблона. Написано что всегда ставит null в конце строки, значит в dst копируется из src sizeof(dst)-1 элементов и затем в dst добавляется в конце null.
Круто.
А вот интересно, что будет если скормить strcpy_s вот это:
char dst[1]; // Статический массив из одного элемента — не строка ибо не так :char dst[] = «a»;!!!
strcpy_s(dst, «A»);
В dst будет только null terminated символ?
Ну в принципе безопасно, но тоже не однозначно.
Ну лан пофиг strcpy и иже с ними пришли из древнего C.
Для наибольшей безопасности, если она так нужна, пользуйтесь string'ом и его перегруженными операторами, insert'ом, replace'ом и т.д.
Я вообще не понимаю, почему бы Микрософту не сделать свой API совместимым с STL.
Наверно потому, что нужна поддержка C и таких программистов очень много. Сейчас кстати C и C++ развиваются разными путями. Например в C есть ключевое слово restrict. В C++ его нет и не предвидится.
Страуструп здесь маху дал. Надо бы было поддержку C11 включить в стандарт C++11 или хотя бы в C++14 ну или в C++17
Иначе мы получим несовместимость, некроссплатформенность, кучу геммора при попытке скомпилить современный Си код вместе с C++ кодом в одной единице трансляции и два разных языка, которые в принципе могли бы быть одним единственным, как было в 80 — 90 годах
Жесть, одним словом (((