Естественно никаких. Кроме того, что я пакет поставил на снег на 2 минуты, пока толкал машину, а рядом не было ни души. Украсть пакет там просто физически не кому было. Но за реальное доказательство понятное дело такое не катит.
Когда я был школьником — у меня взрослый дядька кроссовки! спёр.
Картина была такая, идем со школы с одноклассниками, мужик застрял на девятке и не может выехать, попросил толкнуть. Мы толкнули, а когда он уехал — пропала моя сменка, которую я положил рядом, перед тем как толкать машину.
Так как район был маленький, то обойдя его я нашел ту самую машину, припаркованную во дворе. Поспрашивав людей, живущих рядом — я нашел и квартиру хозяина. Собственно это оказался тот самый мужик, который нас и просил толкнуть. На мои вопросы про кроссовки он морозился, и говорил мол меня в первый раз видит, нигде не застрявал, никто его не толкал и никаких кроссовок он не брал, иди отсюда мальчик.
Ну а потом я пошел домой, и дома мне от родителей влетело за «потерянные» кроссовки.
Совсем забыл, кстати докладываю. Алгоритм Мейстера я реализовал на CPU, и на CPU он показал лучшие результаты среди всех алгоритмов. Так что на CPU он мастхев. А вот на GPU эффективно положить этот алгоритм у меня пока не вышло (из-за особенности устройства GPU), и пока Jump Flooding опрежает его. Но у меня есть идея что можно еще попробовать, чтобы ускорить его. Может быть когда-нибудь я это попробую.
Хорошее — 500 объектов попадающих на отрисовку отправляются всего за 1 мс — не рекорд, но очень даже неплохо.
Вангую, что там неправильно считается эта одна миллисекунда. Ботлнек явно CPU (ибо gpu тратит всего 2мс на фрейм, и при таком «графоние» я верю, что там больше 2мс делать нечего). Так вот, куллинг 11мс + 1мс на дравколлы. При этом FPS в районе 50. А 50 кадров в секунду — это 20мс на кадр. Внимание вопрос: «Где еще 8 миллисекунд?»
Почему я грешу на измерение draw? Потому что GAPI асинхронный, и стоимость вызова draw может сместится в сторону SwapBuffers, т.к. на момент вызова draw мы только сабмитим данные. Реальный же draw произойдет позже.
upd. Хотя я посмотрел тут на график выше, и вряд ли draw был перенесен на SwapBuffers. Но вот 8 миллисекунд все таки потерялись:
Непосредственно перед Draw и после Draw. Примерно по 4мс с каждой стороны.
Мне кажется нужно не крутить зеленый, а желтый. Чтобы между карсным и зеленым образовалась дыра. Т.е. это не банальная корректировка чисто зеленого или чисто красного, а занижение именно пары зеленый + красный. Сделать это можно через какой-нибудь SetDeviceGammaRamp на винде. На линуксах как не знаю.
Насколько я понял очки ослабляют именно перекрывающиеся диапазоны чувствительности разных колбочек. Например красного и зеленого. Далее уже работа мозга, которому становится проще различать цвета.
Ладно, что они отказались от отдельного аудиовыхода. Но я вот чего непонимаю. 3.5мм разъем черт возьми был идеальным разъемом с точки зрения потребителя. Он круглый, и джек свободно вращается в разъеме. Он хорошо фиксируется за счет канавки на джеке. Он легко вставляется, за счет конуса на кончике джека. Его можно легко воткнуть будучи пьяным, и в слепую не вынемая телефона из кармана.
Форма разъема и джека — это то, во что должен был превратиться USB Type C. Но вместо того, чтобы унаследовать формфактор от 3.5мм эппл родила непонятную отрыжку в виде лопатки с дыркой. И по факту пользоваться этой лопаткой так же неудобно, как и предыдущим разъемом.
До glClipControl на десктопах можно было получить reverse depth экзотическим способом. Была такая функция glDepthRangeNV, которая позволяла поменять маппинг. Ну и люди применяли glDepthRangeNV(-1, 1), то есть избавлялись от преобразования [-1;1] -> [0; 1]. Далее просто делаем матрицу проекции как в DirectX, ну и для уверенности выставляем gl_ClipDistance по z, чтобы наверняка отрезать пиксели. Короче получали аналогичное поведение как в DX.
Так вот, эта функция glDepthRangeNV посути только для reverse depth техники, и фактически использовалась только с аргументнами glDepthRangeNV(-1, 1). И кроносы решили её узаконить, и внести в «ядро». Так родилась функция glDepthRange. Но кто-то видимо решил, что он уменее всех, и у функции появилась новая фича:
Thus, the values accepted by glDepthRange are both clamped to this range before they are accepted.
И range на который клампались значения функции были [0;1]. Понимаете иронию? Единственная вещь, ради которой использовали glDepthRangeNV — оказалсь невозможна в glDepthRange. В результате после длительной паузы появилась glDepthRangef, которая подобной дурью не обладала, и reverse depth уже можно делать с помощью glDepthRangef. А позже и glClipControl завезли.
Так вот, glDepthRangef есть и на мобилках начиная с ES 2.0. Так что поидее reverse depth там уже можно провернуть (но я на мобилках это не пробовал). А вот WebGL в пролете, да.
Там пишут, что был сделан рефакторинг во множестве областей. То есть не все переписано под C#. В первую очередь C# коснулся UI. Это всякие панели (но пока еще не все). Ядро PCB по прежнему пока на Delphi.
Ну и второй момент — это скрипты в AD. Они изначально имели Delphi синтаксис. Даже если бы ядро PCB переписали на C#, то скрипты остались бы с прежним синтаксисом как минимум из-за обратной совместимости.
Хм, общаюсь с ребятками с Сан Диего и они говорят совершенно противоположное — странно.
Действительно странно. Ведь я один из тех ребятенков. :)
Впрочем вы сами можете убедиться, что GPU для DRC не используется. В Win10 в диспетчере задач есть колонка показывающая использование GPU. Если у вас другая Windows, то можете скачать GPU-Z отсюда: www.techpowerup.com/gpuz
Он тоже показывает использование GPU. После этого просто запустите DRC и посмотрите на это использование.
Про медленную память не совсем понял, речь о ОЗУ?
Да, частоты, тайминги.
Про тротлинг смешно.
Ну почему же? Например чуть хуже система охлаждения, процессор греется на 5 градусов выше, и уходит в тротлинг. Проблема может быть много где. Например на одной машине не стоят драйвера на чипсет. В этом случае DMA запросы скорее всего будет обрабатывать процессор, хотя мог бы делать чипсет. Возможно какой-то другой софт замедляет работу. Но совершенно точно могу сказать, что если у вас железки одинаковые, а DRC при этом работает от 30% до 100% быстрее, то это не заслуга Quadro, а какая-то проблема на второй машине. И если остальное железо прям 1 в 1 совпадает, то вторую машину можно заставить работать с производительностью первой.
У вас неверная информация. Да, доля участия GPU несколько увеличилась, но DRC и длины цепей не считаются на GPU. Это я вам как разработчик Altium Designer-а говорю. И я пишу как раз код, который исполняется на GPU. :)
DRC не использует GPU (вообще не использует), уверяю вас. То, что у вас тесты дают разные результаты — это другая проблема. Может быть правила разные, может память медленная, может CPU уходит в тротлинг.
Скажу по секрету. Там нет никакой специфичной поддержки для инженерных GPU типа Quadro. Если вы замените Quadro P4000 на игровую GeForce GTX 1070 (которая в 2 раза дешевле) — то в AD18 вы получите даже чуть лучшую производительность. Другое дело, что возможно у вас стоит другой софт, для которого Quadro P4000 будет лучше.
Конкретно вариант в статье — дороговатый. Есть аппроксимация через lookup текстуру, которая позволяет добиться pbr рендера в 1 семпл. Но у меня никак не дойдут руки допилить вторую часть статьи про это.
Картина была такая, идем со школы с одноклассниками, мужик застрял на девятке и не может выехать, попросил толкнуть. Мы толкнули, а когда он уехал — пропала моя сменка, которую я положил рядом, перед тем как толкать машину.
Так как район был маленький, то обойдя его я нашел ту самую машину, припаркованную во дворе. Поспрашивав людей, живущих рядом — я нашел и квартиру хозяина. Собственно это оказался тот самый мужик, который нас и просил толкнуть. На мои вопросы про кроссовки он морозился, и говорил мол меня в первый раз видит, нигде не застрявал, никто его не толкал и никаких кроссовок он не брал, иди отсюда мальчик.
Ну а потом я пошел домой, и дома мне от родителей влетело за «потерянные» кроссовки.
Вангую, что там неправильно считается эта одна миллисекунда. Ботлнек явно CPU (ибо gpu тратит всего 2мс на фрейм, и при таком «графоние» я верю, что там больше 2мс делать нечего). Так вот, куллинг 11мс + 1мс на дравколлы. При этом FPS в районе 50. А 50 кадров в секунду — это 20мс на кадр. Внимание вопрос: «Где еще 8 миллисекунд?»
Почему я грешу на измерение draw? Потому что GAPI асинхронный, и стоимость вызова draw может сместится в сторону SwapBuffers, т.к. на момент вызова draw мы только сабмитим данные. Реальный же draw произойдет позже.
upd. Хотя я посмотрел тут на график выше, и вряд ли draw был перенесен на SwapBuffers. Но вот 8 миллисекунд все таки потерялись:
Непосредственно перед Draw и после Draw. Примерно по 4мс с каждой стороны.
Форма разъема и джека — это то, во что должен был превратиться USB Type C. Но вместо того, чтобы унаследовать формфактор от 3.5мм эппл родила непонятную отрыжку в виде лопатки с дыркой. И по факту пользоваться этой лопаткой так же неудобно, как и предыдущим разъемом.
Так вот, эта функция glDepthRangeNV посути только для reverse depth техники, и фактически использовалась только с аргументнами glDepthRangeNV(-1, 1). И кроносы решили её узаконить, и внести в «ядро». Так родилась функция glDepthRange. Но кто-то видимо решил, что он уменее всех, и у функции появилась новая фича:
И range на который клампались значения функции были [0;1]. Понимаете иронию? Единственная вещь, ради которой использовали glDepthRangeNV — оказалсь невозможна в glDepthRange. В результате после длительной паузы появилась glDepthRangef, которая подобной дурью не обладала, и reverse depth уже можно делать с помощью glDepthRangef. А позже и glClipControl завезли.
Так вот, glDepthRangef есть и на мобилках начиная с ES 2.0. Так что поидее reverse depth там уже можно провернуть (но я на мобилках это не пробовал). А вот WebGL в пролете, да.
Ну и второй момент — это скрипты в AD. Они изначально имели Delphi синтаксис. Даже если бы ядро PCB переписали на C#, то скрипты остались бы с прежним синтаксисом как минимум из-за обратной совместимости.
Действительно странно. Ведь я один из тех ребятенков. :)
Впрочем вы сами можете убедиться, что GPU для DRC не используется. В Win10 в диспетчере задач есть колонка показывающая использование GPU. Если у вас другая Windows, то можете скачать GPU-Z отсюда: www.techpowerup.com/gpuz
Он тоже показывает использование GPU. После этого просто запустите DRC и посмотрите на это использование.
Да, частоты, тайминги.
Ну почему же? Например чуть хуже система охлаждения, процессор греется на 5 градусов выше, и уходит в тротлинг. Проблема может быть много где. Например на одной машине не стоят драйвера на чипсет. В этом случае DMA запросы скорее всего будет обрабатывать процессор, хотя мог бы делать чипсет. Возможно какой-то другой софт замедляет работу. Но совершенно точно могу сказать, что если у вас железки одинаковые, а DRC при этом работает от 30% до 100% быстрее, то это не заслуга Quadro, а какая-то проблема на второй машине. И если остальное железо прям 1 в 1 совпадает, то вторую машину можно заставить работать с производительностью первой.