Могут от первого вызова, скажем, ROPы идти  долго, поэтому end of pipe для него будет поздно, но в это же время видеокарта уже может выполнять вершинные шейдеры для второго, третьего, и так далее

Но вообще, TOP то EOP это, вроде, правильно

Вот тут длинная колбаса параллельно длинной колбасе

Ну, короче, все равно нужно смотреть на другие каунтеры

EOP и EOP плохой показатель, в первом вызове будет 100, во втором, третьем и четвёртом по 3, скажем

Понапихают, блять, по 5к дроуколов. А потом сиди и ковыряй

Надо в совокупности смотреть, мне кажется, а не отдельный draw call искать

Ну тут, наверное, опыт нужен. Я так вообще не могу. :(

Параллельные draw callы выполняются на одних и тех же вычислительных ресурсах, причём на разнородных, в каких-то вызовах может быть много вершин, но все полигоны отсекутся, где-то будем упираться в передачу параметров вершин в пиксельный шейдер (причём проблема может быть и с одной, и с другой стороны), где-то мало вершин, но большой кусок фреймбуфера будет покрыт, и будем и пиксельный шейдинг, и ROPы нагружать, а может быть и всего примерно поровну

Так что, если ты, допустим, хочешь одну задачу на 30 микросекунд распараллелить с другой на 20 (чтобы не было 50), у тебя не обязательно получится TOP to EOP 30 и 20 соответственно, и 30 в совокупности в результате

может и 35, и 40, они друг другу могут немного мешать

Это понятно. Просто со всем теперь этим не понятно что делать:D но в любом случае огромное спасибо что разжевал, теперь хоть более-менее понятен масштаб проблем

Область с более-менее длинными колбасятинами надо смотреть, мне кажется, а дальше уже изучать, чего там много

вершин по отношению к пикселям, самих пикселей после early Z, жирность шейдеров (как по обращениям к памяти, так и по ALU), сколько пикселей надо заблендить в итоге

Да видел

Клёвая штука

Если ты про визуализацию

Но а сам пейпер конечно круто