Таблица Брадиса или непосредственное вычисление?
Вычисление арктангенса, арксинуса, арккосинуса на бумаге "вручную" без таблиц Брадиса и калькулятораДобрые люди, помогите пожалуста. Хочу понять как вычислить без таблицы Брадиса, углы в треугольнике.
Повреждена какая-то таблица верхнего регистра или загрузочная таблица каки= то данныхСтолько времени уже прошло, а тебе так никто и не помог. У меня сейчас при включении моноблока.
Нахождение значения без таблицы БрадисаУ меня есть значение которое я нахожу с помощью формулы арктангенса actg(t)=\pi.
Fedor666, более точно прикинул
lon = 0.0000152587890625;// минимальный шаг приращения градусов для значений [128 .. 256) L = lon * pi/180 * R = 0.0000152587890625 * 3.14159265358979/180 * 6 371 000 = 1.6966999 метра
Если хранить в радианах:
lon = 2.38418579101563e-7//шаг приращения для значений [2..4) L = lon * R = 1.51896 метра
Это на экваторе - худший вариант. В наших широтах поменьше чуть будет
Таблицы не используйте! Чтение из памяти намного медленнее, чем тригонометрические операции!
Пример с GPU: 1 такт - mad, mul, add, mov, min, max, abs, sub, neg, slt, sge 4 такта - sin, cos, 1/x, sqrt, pow, log, exp
А выборка из текстуры 2 за такт
Добавлено через 20 минут
18 угловых секунд шага. Для большинства задач графики выше крыши хватит и 5 угловых минут, т.е. 1024 значения,аккурат страница кеша.
Добавлено через 10 минут Кстати пропускная способность памяти GPU обычно как минимум в 2 раза выше пропускной способности памяти CPU, при этом частота самой GPU раза в 3 ниже частоты CPU. Так что таблички на GPU еще более актуальнее чем на CPU.
Добавлено через 12 минут Вообще Float Point в растеризируещем GPU штука излишняя. Достаточно Fixed Point так как все что в пирамиде видимости находится в диапазоне [-1:1], соответственно отсечение может срабатывать еще при перспективном делении по флагу переполнения вверх. Одна тут заковырка - при центральной проекции по ZNear нужно резать до перспективного деления, по остальным плоскостям - после. А вообще Float Point в GPU суют с прицелом на трассировочный конвейер.
Мне вот другое интересно, вы че серьезно хотите забивать кэш этим г*вном? К тому же, gpu сразу может считать и sin и cos одновременно (и много чего еще интересного) Иногда эта операция может занимать даже 1 такт, поскольку разложение на ряды зависит от кол-ва знаков после запятой, а это зависит от точности угла. Не угонитесь вы за чипом.
Пропускная способность не имеет тут никакого значения! имеет значение скорость доступа к памяти (некоторые из типов латентности памяти - показатели таймингов). и GDDR5 в этом не лучше DDR3 или DDR4. да и вообще о памяти говорить тут не нужно, потому что это нереально медленно будет! либо кеш, либо инструкции!
А там они на кой ляд? В 99% случаев вертексный шейдер тупо умножает вертекс на матрицу трансформации. Ну может нормаль на ViewProjection, т.е без проецирования. В пиксельном в все нужные sin и cos получаются из векторного и скалярного произведений векторов взгляда, вектора на источник и нормали. В геометрическом им там тоже делать нечего. Ну разве если в тасселяционном тела вращения крутить а алгоритм брезенхема для окружностей/эллипсов не знать. Ну и разве что хитро сделанные процедурные текстуры считать. Так тогда не в ГСК а в ЛСК грани. Или типа круги на воде по формуле рисовать от центра. Так честный счет конечными разностями ,при котором тригонометрия не нужна, гораздо быстрее, и заморочек вообще нет особенно с отражением волн и т.д.
Добавлено через 3 минуты
А еще больше имеет значение частота использования таблицы. Дернул раз - и она в кеше. Если при этом постоянно пользуется то никуда из кеша не денется.
Добавлено через 5 минут
Когда эта операция занимает один такт мне sin и cos считать не надо. значения известны. Кстати даже в этом случае нужно просчитать как минимум два члена степенного ряда. Либо у чипа тоже где то табличка внутри зашита , а потом рядом уточняет, либо за табличкой вообще никак не угонится.
Добавлено через 9 минут
Упреждающее чтение кеш GPU типа не умеет? Опять же 1024 значения это врядли более чем занимают в кеше 32 вертекса. Если у GPU напряги с нормальной скоростью доступа к таким объемам данных, о какой реал-тайм графике она вообще может мечтать?
Добавлено через 1 час 21 минуту
Так вот как раз о латентности: * К константной памяти - 0 тактов в случае cache hit, 400-600 тактов в случае cache miss. * К кэшу текстур - 400-600 тактов в независимости от того, попали мы в кэш или нет. * К глобальной памяти - 400-600 тактов.
Т.е. потратим 1 раз 400-600 тактов при инициализации шейдера, все остальное время 0 тактов.
причем тут другой чип, сравнение та идет с вашим методом, а не с другим чипом) вы интересно как будете извлекать из памяти сразу оба значения? успокойтесь, не догонит ваша таблица инструкции в реальных условиях)
это если все вершины изменяются по линейному закону, но в игре с реалистичной графикой это не так, все динамические расчеты неровных поверхностей (к примеру, волны) должны менять координаты вершин по синусоидальному закону, тоже самое касается расчета освещения каждого фрагмента поверхности. И к слову, синус выполняется быстрее матричного умножения (sin за 4 такта, vec4*mat4 за 16 тактов, mat4*mat4 за 64 такта). sin и cos очень быстрые операции.
vec4*mat4 - 16 умножений + 9 сложений, mat4*mat4 за 64 - 64 умножения + 36 сложений. Итого 1 умножение + 1 сложение на такт. Разложению в ряд тейлора с учетом предпросчитанной (зашитой в чип) таблицы факториалов при таких раскладах 4 тактов хватит на 2 члена ряда, что будет архинеточно, особенно в окрестности pi/2, либо он подпрягает дополнительные блоки ALU(только почему их так же не подпрягает на маирицах?) либо не 4 такта, либо на помойку такую точность, либо чип сам имеет предпрошитую таблицу, с табличкой коррекции (ну совсем как в таблицах брадиса).
Добавлено через 10 минут
Гораздо меньшее количество чем подсчет суммы степенного ряда. Даже если этот подсчет дико распараллелен, то пользует гораздо меньше блоков ALU, которые в это время могут чем то другим заниматься.
Добавлено через 24 минуты
Только если в сами инструкции таблица уже зашита. Кстати сделать умножение за один такт без предпрошитой таблицы нереально даже целочисленное, не то что floating point. а с табличкой умножения хотя бы тетрад уже можно реализовать в железе умножение "в столбик".
Добавлено через 10 минут
Мне кажется это бесконечный спор, особенно если разговор щас уйдет в физику
Скажу только о простой: 1. форума sin^2+cos^2=1 не имеет ничего общего с разложением на ряды, которые нужны именно, чтобы найти сам sin/cos, а не его квадрат, иначе смысла нет, и вычислив один вы не получите другой из него моментально, и чип не вычисляет один из них, он вычисляет оба одновременно. 2. Умножение выполняется за один такт! 3. Sin выполняется макс за 4 такта с точностью float32 как минимум, и таблицы брадиса там не используются, а используется разложение на ряды, уже очень давно. 4. На счет регистров это все понятно, но я не считаю, что забить кэш значениями синусом это хорошее решение, если вы конечно не только синусы считаете в шейдере. 5. На счет инкремента: это сработает если у вас равномерные углы, а если скажем углы непредсказуемые, и так получится что от 15 до 17 градусов понадобится большая точность по углам, а с 100 до 170 градусов запросов на получение синуса особо и не будет, другими словами получится общая ситуация, из за которых, кстати вообще и придумали числа с плавающей запятой.
А вообще, я считаю что все зависит от конкретной задачи! И определить, что лучше можно только тестами, причем они будут давать разные результаты на разном железе. Но я просто не понимаю зачем усложнять себе жизнь таблицами для, по сути, софтварной эмуляции аппаратных инструкций gpu и cpu более умные люди все уже сделали за нас!
Вот вот. умножение выполняется за один такт. на один член ряда нужно 2 умножения при наличии таблички факториалов или 3 без наличия таковой. итого в 4 такта имеем не более 2 членов ряда тейлора. вопрос откуда точнось float32?
Добавлено через 15 минут
А за одно с ними и погрешность вычислений стала относительной а не абсолютной. Если же нужны вычисления с абсолютной погрешностью то fixed point выигрывает и по скорости (хотя на современных процах уже одинаково) и по точности. к примеру в FP 0.32 можно иметь синус с 32 битами мантиссы а в float32 только с 24. ну и еще пример. к примеру есть карта 100x100 км в которой нужно держать здания с точностью расположения до 1мм float32 при этом в пролете. А Fixed Point справится запросто и не поморщится. с такой точностью потянет до 4294x4294км
Добавлено через 4 минуты
Непосредственное интегрированиеЯ не понимаю как решить 1,5,7,9 . Прошу помощи с решением.
Запретить Непосредственное (полное) УдалениеОбнаружил, что активно действие над объектами "Удалить непосредственно". С ужасом. Как запретить.
Непосредственное удаление из std::listСобственно проблема вот в чем раньше, когда я создавал игру, у меня были самодельные листы типа .
Windows7 Зависание на логотипе и непосредственное включениеЗдравстуйте! Проблем с зависание на логотипа в сети полно, также уйма предлагаемых решений.