Тёмная тема
- innuendo
- Постоялец
=A=L=X=
> Так от того и размножались, что не было переходов на новую версию и приходилось
> тянуть всё старое в попытке слить это старое с чем то совершенно новым.
Если бы баги были только внутри каждого вендора - это бы согласововалось с твоим утверждением. А получалось, что на Nvidia одна картинка, на ATI - другая
innuendo
> Если бы баги были только внутри каждого вендора - это бы согласововалось с
> твоим утверждением. А получалось, что на Nvidia одна картинка, на ATI - другая
Ты в этом обвиняешь расширения или что? Не могу уловить к чему это всё говорится.
innuendo
> А получалось, что на Nvidia одна картинка, на ATI - другая
Дык DirectX один, а OpenGL каждый вендор реализовывает сам. Поэтому и различия бывают и несоответствия со спецификацией. Это проблема открытого стандарта. Vulkan тоже открытый, но благодаря новой архитектуре которая ближе к видеокарте и благодаря отсутствию ненужного хлама, ожидается меньший вес и хорошее качество драйвера (на презентации упоминали об этом).
Например тот-же Mantle у меня не глючил, все работало также как на DX. Единственно на старом драйвере в меню BF4 у меня мышь не попадала в GUI (непонятный баг... причем тут GAPI интересно). Потом починили.
>А что, трудно приделать к Vulkan в качестве расширения?
и почему я должен ждать спецификацию и драйверы еще год, если я могу уже сейчас в gl-e писать код максимальной производительности (которую вулкану еще требуется достичь).
хотя есть один момент, возможно вулкан будет лучше параллелиться. я не могу с разных потоков ввызывать glCaptureRenderState.
=A=L=X=
> Ты в этом обвиняешь расширения или
Неужеле не понятно? Был единый стандарт без местных фич - был общий код
innuendo
> Неужеле не понятно? Был единый стандарт без местных фич - был общий код
Ну может даже запретят расширения, но я лично не думаю что так будет. Более того, почти уверен, что так не будет.
Фичу то кто то может и внедрить, разве в силах кто запретить в DLL-ку внедрить еще одну функцию? Но она не становится от этого стандартом.... до момента принятия новой минорной версии.
Так что я тут не вижу абсолютно никаких проблем. Проблема не в расширениях. Проблема когда устаревшие морально как расширения так и базовые моменты API тянутся с бородатых 80-ых как будто так и надо.
А потом кто-то удивляется "а почему там миллионы строк кода и на любой чих 100500 проверок?
=A=L=X=
> устаревшие морально как расширения
не довод
=A=L=X=
> Так что я тут не вижу абсолютно никаких проблем. Проблема не в расширениях.
и
> Проблема когда устаревшие морально как расширения так и базовые моменты API
диссонанс. Так пофиг или нет? Ведь не мешает?
clc
> Ведь не мешает?
Уже до Кроноса дошло, что мешает и что несерьёзно всё это. Надо что-то менять.
Ну и правда, посмотрим сперва во что Вулкан превратится и посмотрим. Тема про говноапи была в другом месте.
Кстати, вопрос.
Идея, почему Rasterizer и Blend State и все шейдеры формируют Pipeline State Object — понятна.
Почему же туда не входят Depth Stencil State и Sampler State?
Теоретически, может оказаться, что на каком-нибудь новом GPU смена Depth Stencil State или Sampler State будет приводить к необходимости менять хардварный шейдер.
И тогда установка Pipeline State'а опять станет дорогой, опять новые API и т.д. и т.п.
По крайней мере, в Apple Metal и в DX12 (судя по слайдам) реализовано действительно так.
Demiurg-HG
> Кстати, вопрос.
На него тебе может ответить только человек разрабатывающий чипы. Там просто и вдруг не бывает. Очень вероятно что на уровне кремния всё вполне очевидно, что и с чем может или не может быть/стать в обозримом будущем.
Bishop
> На него тебе может ответить только человек разрабатывающий чипы. Там просто и
> вдруг не бывает. Очень вероятно что на уровне кремния всё вполне очевидно, что
> и с чем может или не может быть/стать в обозримом будущем.
Кстати, ответ нашел:
https://fgiesen.wordpress.com/2011/07/04/a-trip-through-the-graph… -2011-part-4/
Вкратце, как я понял, наивная реализация сэмплера подразумевает пересылку примерно 24–40 байт (u, v, du/dx, dv/dx, du/dy dv/dy, ...) на одну выборку.
Поэтому в Shader Core этим ни кто и не занимается, а занимается этим очень тупой, но очень быстрый Texture Unit. И установка сэмплеров подразумевает настройку именно этого юнита.
C DepthStencil пока не ясно...
Причем вдвойне не ясно, т.к. DepthStencilState определенно зависит от RasterizerState'а и от Pixel Shader'а (ибо всякие Early Z), и даже от BlendState'а, т.к. MSAA и Alpha-to-Coverage!
Demiurg-HG
Ну, видимо, по аналогии с Texture Unit, есть специально обученые островки транзисторов, называемые ROP, которые умеют например хотя бы https://ru.wikipedia.org/wiki/HyperZ
Iron Man
> А почему такая разница в количестве кода?
из-за заполнения структур. на самом деле если делать по уму кубик в OGL с установкой всех стейтов - будет вообще одинаковое количество строк кода.
А кроме того вроде в DX можно не писать структуры а передавать нули, тогда вроде будет по дефолту (но я не уверен, не пробовал, а только видел), а значит снова будет равное число строк
war_zes
> из-за заполнения структур. на самом деле если делать по уму кубик в OGL с
> установкой всех стейтов - будет вообще одинаковое количество строк кода.
В OpenGL стейт не фиксированный, там нет смысла ставить все стейты. В любой момент может появится часть стейта из какого-то расширения, которое может быть, а может и не быть.
bazhenovc
> В OpenGL стейт не фиксированный, там нет смысла ставить все стейты
Ага, а потом гадать, откуда вылезли баги....
Ведь в любой момент окажется что стейт стоит совершенно не тот, который мы ожидаем. Так что как минимум нужно проставлять все основные стейты... чего конечно же в уроках про кубик никто не делает.