Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / GLSL alphablend? (2 стр)

GLSL alphablend? (2 стр)

Поделиться

Страницы: 1 2 3 Следующая

Iron ManПостоялецwww10 ноя. 20173:26#15
gamedevforПользовательwww10 ноя. 20173:39#16
Suslik
То есть ты думаешь что вызовы glEnable(GL_BLEND); / glDisable(GL_BLEND); очень легкие по производительности?
SuslikМодераторwww10 ноя. 20173:41#17
gamedevfor
я не думаю, я знаю, что переключение стейта будет типично дешевле, чем увеличение bandwidth в два раза, что за глупый вопрос?
gamedevforПользовательwww10 ноя. 20173:43#18
Suslik
Ну кто знает что там OGL делает, если флажок меняет это одно, а если будет создавать какие то буфера то это другое.
boolПостоялецwww10 ноя. 201713:39#19
gamedevfor
ну, когда терзают сомнения по поводу скорости, очевидно, лучше провести тест, чем гадать на форуме и кофейной гуще) так-то считай dst будет читаться, как Suslik выше сказал, только для каждого пикселя. А пикселей куда больше, чем один стейт. Но лучше тесты проводить и там, где не нужен бленд, выключать его, а не умножать на ноль.
gamedevforПользовательwww10 ноя. 201717:44#20
bool
Может OGL и не настолько дурной чтобы читать dst для того чтобы потом его умножить на 0. А это значит что вполне вероятно что OGL в этом случае читать dst не будет вовсе.
boolПостоялецwww10 ноя. 201720:44#21
gamedevfor
то есть, ты считаешь, что разработчики драйверов должны были подумать о том, что если вдруг кому-то лень выключить alphablend, то они будут отключать его если DST_FACTOR == 0? а зачем тогда оставили возможность включить/выключить стейт? а если у тебя DST_FACTOR == 1, а dstPixel.alpha == 0?
gamedevforПользовательwww10 ноя. 201722:26#22
bool
> alphablend, то они будут отключать его
Не нужно ничего отключать, а тупо не читать dst.

bool
> dstPixel.alpha == 0
Очевидно что в таком случае оптимизировать не получится.

bool
> а зачем тогда оставили возможность включить/выключить стейт?
Неизвестно. Я предпочёл бы указывать флаги для блендинга в самом шейдере - так намного удобнее и правильнее как мне кажется.

ChebПостоялецwww10 ноя. 201723:52#23
Шейдер и блендер - две совершенно разных части механизма, не знающих друг о друге. Тут где-то статья болталась, почему нельзя читать из выходного буфера в шейдере - причина тут та же. Мешало бы аппаратным оптимизациям, и видяхи были бы в несколько раз медленнее. Вывод помню, как он выводится - забыл.
MrShoorУчастникwww11 ноя. 20173:39#24
Cheb
> Тут где-то статья болталась, почему нельзя читать из выходного буфера в шейдере - причина тут та же.
Справедливости ради частенько это работает как ожидается. Если через графический API можно было бы добавлять ручками точки GPU-GPU синхронизации, то можно было бы относительно безопасно читать из буфера, в который собираешься писать.

> Мешало бы аппаратным оптимизациям, и видяхи были бы в несколько раз медленнее.
ROP-ы (юниты, которые собственно занимаются блендингом и поздним тестом стенсила/глубины) отделены от шейдерных вполне логично. Они делают сложные подкапотные штуки, типа сортировки пикселей в порядке поступления треугольников, позднего теста глубины/стенсила, которые могут включать распаковку буферов и иерархические тесты. Ну и потом собственно делают блендинг. Короче это сложный механизм, который не так просто отдать на руки программисту, хотя после ROP можно было бы запилить шейдер блендинга. Кроме того они позволяют равномернее нагрузить шину, и работает это так:

Шейдерные юниты сбрасывают пиксели в буфер, а ROP-ы этот буфер разгребают. Шейдерные юниты могут набрасывать пиксели с любой скоростью. Иногда намного быстрее, чем позволяет память, а иногда наоборот дольше. И чтобы сгладить участки, когда то густо то пусто, и придумали ROP-ы. Зато теперь нельзя читать из того буфера, куда ты пишешь, потому что если затык на ROP-ах, то есть риск получить очень старые данные (которые например еще 5 дравколлов назад были).
Поэтому программист копирует текстуру во временную текстуру. Копирование текстуры приводит к установке точки GPU-GPU синхронизации. Поэтому реальное копирование произойдет только тогда, когда ROP-ы разгребут все пиксели, которые надо блендить. Но само копирование посути нафиг не нужно. Если я собираюсь рисовать 1 в 1, т.е. почитать пиксель и потом его перерисовать, то нафига копировать то? Нужна лишь GPU-GPU точка синхронизации.

p.s. Вулканы/D3D12 еще тщательно не смотрел, но в них наконец то добавили Fence. Поэтому вероятно теперь наконец то можно читать из текстуры, в которую пишешь.

Правка: 11 ноя. 2017 3:41

MrGobusПользовательwww11 ноя. 201714:04#25
Возможные причины

1. В текстуре значение альфа канал 0.
Можно попробовать в шейдере финальному цвету задать альфу = 1.

GLSL

  ...
  fragColor = texture(smpler, fragTexCoord);
  fragColor.a = 1;
  ...

Попробовать с внутреннем форматом RGB а не RGBA

2. Убедится что альфа = 1 в glClearColor(0, 0, 0, 1);

Не забыть glClear() =) желательно с GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT

innuendoПостоялецwww11 ноя. 201714:09#26
MrShoor
> p.s. Вулканы/D3D12 еще тщательно не смотрел, но в них наконец то добавили Fence

а в старых API fence не было ?

gamedevforПользовательwww11 ноя. 201719:49#27
Cheb
> Шейдер и блендер - две совершенно разных части механизма, не знающих друг о друге.

Можно было бы добавить в код шейдера GLSL хинты которые позволяли бы правильно настроить окружение.

MrShoorУчастникwww11 ноя. 201720:01#28
innuendo
> а в старых API fence не было ?
А было?
innuendoПостоялецwww11 ноя. 201720:17#29
MrShoor
> > а в старых API fence не было ?
> А было?

https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_sync.txt

устроит?

Страницы: 1 2 3 Следующая

/ Форум / Программирование игр / Графика

2001—2017 © GameDev.ru — Разработка игр