Вышел PixelLight 1.0.0

А не допускаете, что ситуация такая же, как в случае KWin - ни один из разработчиков банально не пользуется fglrx, хотя для всех других драйверов различные code path есть?

Допускаю, но тогда не совсем логичным выглядит использование (по дефолту, без проверки) для fglrx кода, который был написан для NV. Всё таки меса более референсная, и для непроверенных драйверов было бы логично использовать код, который отлажен был с ней.

Костыль он приделал, чтобы не связываться с разработчиками композитного менеджера...

А может, он просто убрал лишний ассерт, и совсем ничего не приделал? А может, он решил, что не сможет убедительно обосновать наличие лишнего ассерта, и по тому решил не связываться с разработчиками?

...потому что если попробовать с ними взаимодействовать, можно получить ответ в духе «ПНХ».

Честно говоря, совершенно не увидел тут ПНХ. Какой-то патч приняли и поблагодарили кого-то.

Что имеем: лояльная обработка неопределённого поведения в драйвере nVidia, привела к тому

... что дрова инвидии все (кроме поборников ассертов) считают хорошими, а каталист считают глючным. Конкурентная борьба, ничего особенного. Думаете, инвидия сейчас же побежит ставить ассерты, чтобы и её драйвера начали так же падать? Вы бы так поступили на их месте? :) Тогда и не надо им это советовать. Ни один чел в здравом уме не поврит, что хорош тот драйвер, с которым падает куча прог, и плох тот, с которым всё работает. И про нарушение спеков _драйвером_ тоже ни кто не поверит - это фигня.

Вы мне ответьте на простой вопрос: почему, и согласно какой спецификации, там _должен_ стоять ассерт? Он там может стоять, равно как может и не стоять. А поскольку никаких серьёзных причин ему там быть, не наблюдается, а только лишние падения - его и убрали нафиг. Кому стало хуже? Кому конкретно?

Допускаю, но тогда не совсем логичным выглядит использование (по дефолту, без проверки) для fglrx кода, который был написан для NV. Всё таки меса более референсная, и для непроверенных драйверов было бы логично использовать код, который отлажен был с ней.

По поводу логичности решений, применённых в коде Metacity - это не ко мне.

А может, он просто убрал лишний ассерт, и совсем ничего не приделал?

На такое изменение тоже приходится тратить ресурсы (QA).

А может, он решил, что не сможет убедительно обосновать наличие лишнего ассерта, и по тому решил не связываться с разработчиками?

Я уже привёл пример связи с разработчиками - KWin. Даже при том, что баги на стороне fglrx были поправлены, разработчики KWin отказались трогать блеклист fglrx мотивируя это тем, что никто из них им не пользуется (причём баги были поправлены по их просьбе). Не, ну нормально?

Какой-то патч приняли и поблагодарили кого-то.

Патч написан AMD, поблагодарили сотрудника AMD (Jammy Zhou).

Честно говоря, совершенно не увидел тут ПНХ.

Если бы AMD не написали этот патч - direct-рендринг для fglrx в KDE 4.10 никто не включил бы. Я лично удивлён тому, что Catalyst Team были вынуждены потратить время на ковыряние чужого кода, писать патч для него, вместо того, чтобы заниматься своими прямыми обязанностями - работой над fglrx.

Конкурентная борьба, ничего особенного.

В духе embrace, extend and extinguish.

Думаете, инвидия сейчас же побежит ставить ассерты, чтобы и её драйвера начали так же падать?

Куда и зачем они побегут - их дело, лишь бы их понимание спецификаций не оказывало влияние на всех остальных (но, по факту, оказывает).

Ни один чел в здравом уме не поврит, что хорош тот драйвер, с которым падает куча прог, и плох тот, с которым всё работает.

Я считаю что лучше тот OpenGL-драйвер, в котором более строго реализована спецификация OpenGL (естественно это не единственный критерий, но в данном контексте ограничимся им). По данному критерию поддержка OpenGL 1-3 в Mesa лучше, чем в fglrx (в который уже успели понатыкать костыли для WINE, Metacity и Ънтырпрайзного софта). Меня, к слову, в своё время опечалили намерения Intel добавить workaround для Unigine Sanctuary в Mesa. Доктор, я здоров?

Вы мне ответьте на простой вопрос: почему, и согласно какой спецификации, там _должен_ стоять ассерт? Он там может стоять, равно как может и не стоять. А поскольку никаких серьёзных причин ему там быть, не наблюдается, а только лишние падения - его и убрали нафиг. Кому стало хуже? Кому конкретно?

Это просто разные подходы: lazy и strict (если в спеках написано «нельзя», значит отправка кривого шейдера приведёт к тому, что он не скомпилируется). Вы и nVidia сторонники первого, Catalyst Team и разработчики Mesa - сторонники второго. Неужели и правда нужно пояснять, к чему приводят подобные послабления? У вас ведь куча примеров перед глазами.

разработчики KWin отказались трогать блеклист fglrx мотивируя это тем, что никто из них им не пользуется

Вероятно, раз никто не пользуется, то никто и не протестировал работу после исправления. Нельзя ж без хотя бы минимального тестирования трогать блеклист. Внимательно я тот трид не читал.

Я считаю что лучше тот OpenGL-драйвер, в котором более строго реализована спецификация OpenGL

Внимание: спецификация OpenGL в обоих реализована абсолютно строго. Различия появляются лишь тогда, когда юзер выходит за рамки спецификации. Соответственно, спрашиваю повторно: чем, по-вашему, каталист в этом плане лучше? В рамках OpenGL они одинаковы и совершенно строги, а вне его - он берёт и падает.

если в спеках написано «нельзя»

В том то и дело, что в спеках не написано «нельзя». В спеках только написано, какие входные данные и действия к чему должны привести. Если ваши входные данные подпадают под спек, то вы в нём смотрите, чего вам стоит ждать. Если не подпадают - значит, вы работаете за рамками спека, но «нельзя» он вам не говорит никогда. Это важный момент, осознайте, что спек ничего не запрещает, в худшем случае он может вам про undefined behavior сказать, но это не наш случай.

Вероятно, раз никто не пользуется, то никто и не протестировал работу после исправления. Нельзя ж без хотя бы минимального тестирования трогать блеклист. Внимательно я тот трид не читал.

Работу KWin с direct rendering на fglrx люди тестировали два месяца (например тред на ЛОРе).

Внимание: спецификация OpenGL в обоих реализована абсолютно строго.

Цитата из спецификации: The #version directive must occur in a shader before anything else, except for comments and white space.
Реализация nVidia: only preprocessor codes could be placed before «version».
Утверждение «спецификация OpenGL в обоих реализована абсолютно строго» - некорректно, так как реализация nVidia обрабатывает шейдеры, несоответствующие спецификации.

чем, по-вашему, каталист в этом плане лучше?

Тем, что выкидывала ошибку при попытке скомпилировать кривой шейдер, т.е. информировала разработчика (который соблаговолит прочитать текст ошибки) о выходе за рамки спецификации (см. последний backtrace из багрепорта - там вполне конкретное сообщение об ошибке в одном из потоков). Кроме того реализация исключительно оговорённого спецификацией освобождает ресурсы для решения реальных проблем пользователей и исправления реальных багов. Возможно, именно по этой причине мы имеем наличие поддержки MUX-less PowerXpress в Catalyst для Linux и отсутствие поддержки Optimus в драйвере nVidia?

а вне его - он берёт и падает

Где вы прочитали, что Catalyst падает при попытке компиляции кривого шейдера?

В том то и дело, что в спеках не написано «нельзя».

Но и не написано, что можно, а для многих (в том числе программистов) «работает на блобе nVidia» означает, что должно работать везде, хотя это не так.

значит, вы работаете за рамками спека

Зачем поощрять выход разработчиков за рамки спецификации игнорированием их ошибок? Польза в кратковременной перспективе, а в долговременной - вред и необходимость городить костыли на костылях. Порочность такого подхода у нас уже была возможность оценить на примере WINE.

Если не подпадают - значит, вы работаете за рамками спека, но «нельзя» он вам не говорит никогда.

Это важный момент, осознайте, что спек ничего не запрещает, в худшем случае он может вам про undefined behavior сказать, но это не наш случай.

Не в данном случае, но вообще говоря в спеках OpenGL хватает прямых запретов.

Цитата из спецификации: The #version directive must occur

Чтобы прога соответствовала стандарту, должно быть именно так. В противном случае - unspecified. Запрета тут нет. Все «must» надо понимать как «to comply to the standard, it must...», и никак иначе.

Утверждение «спецификация OpenGL в обоих реализована абсолютно строго» - некорректно, так как реализация nVidia обрабатывает шейдеры, несоответствующие спецификации.

Обработка шейдеров, не соответствующих спецификации - не есть нарушение спецификации, так как спецификация на них вообще не распространяется. Почему вы считаете, что обработка их ассертом - правильная обработка? Я уже спрашивал, где это написано, и почему вы так уверены, что это - единственная правельная обработка. Вы не ответили пока.

Тем, что выкидывала ошибку при попытке скомпилировать кривой шейдер

Не кривой, а лишь не стандартный. Где сказано, что должен выкидывать ошибку, и, главное, какую именно? Ответьте, пожалуйста, на этот прямой вопрос.

Но и не написано, что можно

Если бы было написано, что можно, то было бы всё в рамках стандарта. Раз не написано, что можно - значит, вне стандарта.

а для многих (в том числе программистов) «работает на блобе nVidia» означает, что должно работать везде, хотя это не так.

Согласитесь, что авторы блоба в этом не сильно виноваты? :) Они подобные слухи не распускали.

Зачем поощрять выход разработчиков за рамки спецификации игнорированием их ошибок?

А почему обязательно ошибок? Ошибки - это если програмер начал на undefined behavior закладываться, а на unspecified многие закладываются добровольно: http://ru.wikipedia.org/wiki/Неуточняемое_поведение

В отличие от неопределённого поведения, программа с неуточняемым поведением с точки зрения соответствия спецификации языка не считается ошибочной

Порочность такого подхода у нас уже была возможность оценить на примере WINE.

Дайте, чтоль, ссылку на форум вайна, где это обсуждается компетентными людьми - уже интересно стало.

Не в данном случае, но вообще говоря в спеках OpenGL хватает прямых запретов.

Примеры плиз. Спек не должен содержать запретов, ни прямых, ни косвенных. Максимум, может неопределённым поведением запугивать.

Чтобы прога соответствовала стандарту, должно быть именно так. В противном случае - unspecified. Запрета тут нет. Все «must» надо понимать как «to comply to the standard, it must...», и никак иначе.

Обработка шейдеров, не соответствующих спецификации - не есть нарушение спецификации, так как спецификация на них вообще не распространяется. Почему вы считаете, что обработка их ассертом - правильная обработка? Я уже спрашивал, где это написано, и почему вы так уверены, что это - единственная правельная обработка. Вы не ответили пока.

Не кривой, а лишь не стандартный. Где сказано, что должен выкидывать ошибку, и, главное, какую именно? Ответьте, пожалуйста, на этот прямой вопрос.

Если бы было написано, что можно, то было бы всё в рамках стандарта. Раз не написано, что можно - значит, вне стандарта.

Во-первых я уже писал, что это просто разница в подходе (lazy/strict) что последствия lazy негативны и это очевидно. Во-вторых я писал, что вы можете сами спросить у Пьера. Ну и в-третьих добавлю напоследок, что обработка вот конкретно #version строгая не только в Mesa и fglrx, но и в QGLShader, а так же реализации OpenGL в OS X и iOS, так что смысл спрашивать как бы отпадает.
Почему-то все эти люди в данном случае читают слово «must» одинаково и если склонен доверять их пониманию, как и пониманию лично Пьера. Почему-то они распространяют спецификацию на шейдеры, не соответствующие ей. Почему-то они все эти драйвера выкидывают ошибку в данном конкретном случае. И nVidia, кстати, сделали свою реализацию обработки #version более строгой (раньше #version можно было писать даже в последней строке, и шейдер всё равно компилировался на блобе nVidia). С чего бы это всё, как считаете?

Согласитесь, что авторы блоба в этом не сильно виноваты? :) Они подобные слухи не распускали.

Ну если вы не заметили, что весь курс nVidia направлен на vendor lock-in различными методами (CUDA, PhysX GPU и такая вот реализация OpenGL) то я уж не знаю :)
Посмотрите ещё на mplayer и VDPAU - nVidia как бы и ни при чём, но в итоге в дефолтных репозиториях всех дистрибутивов mplayer только с VDPAU.

А почему обязательно ошибок? Ошибки - это если програмер начал на undefined behavior закладываться, а на unspecified многие закладываются добровольно

То есть вы полагаете, что разработчики Metacity сделали его несовместимым с fglrx добровольно? Интересная версия. Почему вы так считаете?

Я, допустим, часто использую всякие GNU extensions, которые, с точки зрения спецификации С, являются unspecified. Но я лучше вставлю в свой код 5 строк, использующих GNU extension, чем 1000 строк без его использования.

А кто-то использует свойства с префиксом webkit в CSS, но почему-то этому совсем не рады. Видимо потому что в итоге это приводит к такому вот безобразию.

Дайте, чтоль, ссылку на форум вайна, где это обсуждается компетентными людьми - уже интересно стало.

К сожалению большая часть годных примеров осталась в предыдущем багтрекере fglrx, а в новом их нет, т.к. разработчики WINE пришли в чувство, и разработчики fglrx со своей стороны пошли на некоторые уступки. Однако традиция разработчиков WINE реализовывать что-то не раньше, чем оно появится в драйверах nVidia осталась и сейчас - например поддержка xradnr в WINE появилась только тогда, когда nVidia сменили TwinView на xrandr в блобе. (Хотя может быть дело удачном сочетании факторов и том, что после Humble Indie Bundle V у нас с Джеффри Розеном, президентом Wolfire Games, и Джеймсом Рэми, вице-президентом CodeWeavers, состоялся разговор на повышенных тонах о поддержке многомониторных конфигураций сборкой Crossover в дистрибутиве Limbo для Linux; при запуске Limbo все мониторы, кроме первого, отключаются, даже если запуск происходит в оконном режиме; Джеймс полагал что я своим багрепортом о проблемах с CrossOver троллю CodeWeavers и устроил истерику, предлагая Джеффри вернуть мне деньги за Бандл, да послать куда подальше.)

Примеры плиз. Спек не должен содержать запретов, ни прямых, ни косвенных. Максимум, может неопределённым поведением запугивать.

Откройте спеки OpenGL и пройдитесь по всем упоминаниям «not allowed».

Во-первых я уже писал, что это просто разница в подходе (lazy/strict)

Я с этим не согласился, так как додумывание спеков каждым отдельным разработчиком и внесение отсебятины - уж точно strict назвать нельзя никак. То, что вы называете strict, на самом деле лишь наихудшая из всех возможных обработка неописанных ситуаций. Видимо, мы, в рамках ЛОР, ничего друг другу так и не сможем доказать, так как тут нужна статья, которая бы объясняла область рименения спеков, трактовку различных терминов из них, и тд. Найти такую не просто...

Ну и в-третьих добавлю напоследок, что обработка вот конкретно #version строгая не только в Mesa и fglrx, но и в

А что значит строгая? Наверняка, во всех перечисленных вами случаях, ошибки возвращаются разные, и тд. Какая тут строгость, если они сами нафантазировали, что нужно возвращать и как поступать?

Ну если вы не заметили, что весь курс nVidia направлен на vendor lock-in различными методами

Если они предлагают решения и расширения, которые нравятся юзерам, которые активно используются и тд - то честь им и хвала, и всё тут. Очень многие их наработки в последствии входят в спеки.

То есть вы полагаете, что разработчики Metacity сделали его несовместимым с fglrx добровольно?

В данном случае - может и нет, я не знаю предыстории. Однако, очень напрягает, когда можно изящно решить проблему, использовав вкусное расширение, или же извращаться, но зато оставаться в рамках стандарта. Каждый программист сам для себя решает, как ему поступить в такой ситуации. Я против того, чтобы это решение навязывалось кем-то из вне. А вы, видимо, за... Хотя, на вашем месте, я бы ратовал за расширение спеков, а не за ассерты. Вот работает теперь этот грёбаный #version где угодно - ну так порадуйтесь, да обновите спеки! А не откатывайте людей назад, в каменный век. :)

Откройте спеки OpenGL и пройдитесь по всем упоминаниям «not allowed».

Сделал - всего около 5 совпадений поиска, по всему спеку! И вот пример:

It is not allowed to have variables of different sampler types pointing to the
same texture image unit within a program object. This situation can only be
detected at the next rendering command issued, and an INVALID_OPERATION
error will then be generated.

Видимо, мы, в рамках ЛОР, ничего друг другу так и не сможем доказать, так как тут нужна статья, которая бы объясняла область рименения спеков, трактовку различных терминов из них, и тд. Найти такую не просто...

И, видимо, на английском, потому что мужики из Intel, AMD и Apple не в курсе. Можно ещё поинтересоваться, что там в драйверах у ARM, Qualcomm, Texas Instruments и Imagination Technologies, но я уверен, что самодеятельностью в духе nVidia никто больше не занимается.

Какая тут строгость

Простая - отказ от поддержки чего-либо, выходящего за пределы спецификации.

Хотя, на вашем месте, я бы ратовал за расширение спеков, а не за ассерты.

Ратовать за расширение спеков должны люди типа Кармака. Ещё скорее всего сейчас поступают пожелания от Valve (ждём-с безкостыльный многопоточный рендеринг в OpenGL 5).

порадуйтесь, да обновите спеки!

http://www.khronos.org/about/contact

всего около 5 совпадений поиска, по всему спеку

Вы одной версией OpenGL не ограничивайтесь :)

с предварительным выдумыванием того, какую бы ошибку лучше вернуть

А что, по-вашему, лучше когда у каждого вендора будут дополнительные негласные правила в драйверах? Вендоров на вскидку как минимум восемь. Представляете себе масштабы возможного бардака? Сейчас, с учётом различного железа, различных версий драйверов с различными багами на различных платформах, и так уже очень несладко, а вы уверены, что к этому нужно добавить ещё больше проблем для разработчиков драйверов и ПО. Вот зачем?

что самодеятельностью в духе nVidia никто больше не занимается.

Почему вы не допускаете, что в NV не самодеятельность, а просто отсутствие кучи лишних проверок, которые соотрудники АМД так тщательно расставляли, занимаясь самодеятельностью?

Простая - отказ от поддержки чего-либо, выходящего за пределы спецификации.

... с выходом за пределы спецификации в плане возврата ошибки. Чем этот выход за пределы лучше первого? Ах да, для отладки кому-то пригодится, но не кажется ли вам, что на соответствие стандарту _при отладке_ должен всё-таки не драйвер проверять, а какая-то специально для этого разработанная тулза? А вот на соответствие стандарту _при работе_ - проверять вообще глупо - только падения создавать юзеру.

Ратовать за расширение спеков должны люди типа Кармака.

Ну а реально ратует инвидия, и ведь расширяет же во всю.

А что, по-вашему, лучше когда у каждого вендора будут дополнительные негласные правила в драйверах?

Это - процесс естественного отбора и эволюции. Сначала каждый вендор делает что-то своё, потом юзера смотрят, что из этого их интересует, потом начинается куча проблем совместимости (увы, хотя каждый отдельно взятый программист всегда имеет право не использовать никакие расширения), а потом самый жизнеспособный вариант попадает в спек, и все снова счастливы. Если же этап с проблемами совместимости искоренить насильственными методами, то мотивации в расширении спеков значительно поубавится. У всего есть свои плюсы и минусы - главное лишь в том, чтобы каждый программер сам для себя решал, на чьей он стороне, и хочет ли он гемор ради соблюдения стандарта, или же ему больше по душе гемор с портабельностью. Это его выбор. И если, допустим, Линус решил все необозначенные позиксом моменты обрабатывать наиболее лояльно, то я считаю, что такому подходу можно доверять.

Мы с вами хотя бы пришли к тому, что со стороны инвидии нарушений стандарта нет? Что все вопросы лишь в обработке неописанных моментов? Если пришли, то я и этим вполне удовлетворён. :)

Мы с вами хотя бы пришли к тому, что со стороны инвидии нарушений стандарта нет?

Почему вы не допускаете, что в NV не самодеятельность, а просто отсутствие кучи лишних проверок, которые соотрудники Intel, AMD и Apple (а так же скорее всего ARM, Qualcomm, Texas Instruments и Imagination Technologies) так тщательно расставляли, занимаясь самодеятельностью?

Я пофиксил ваш вопрос, но после фикса вопрос получился какой-то дуратский. Как считаете, проблема в фиксе или в вопросе?

... с выходом за пределы спецификации в плане возврата ошибки. Чем этот выход за пределы лучше первого?

Например тем, что сама же nVidia постепенно движется от lazy к strict, а остальные уже придерживаются strict.

А вот на соответствие стандарту _при работе_ - проверять вообще глупо - только падения создавать юзеру.

То, что в Metacity код шейдера не соответствует стандарту и ошибки при его компиляции не обрабатываются - проблемы Metacity. KWin, в случае проблем с драйвером, перезапускается прекращая использовать OpenGL, но пользователь не теряет запущенные приложения и данные из них.

Ну а реально ратует инвидия, и ведь расширяет же во всю.

Вы ещё все заслуги по развитию OpenGL nVidia припишите.

Это - процесс естественного отбора и эволюции. Сначала каждый вендор делает что-то своё, потом юзера смотрят, что из этого их интересует, потом начинается куча проблем совместимости (увы, хотя каждый отдельно взятый программист всегда имеет право не использовать никакие расширения), а потом самый жизнеспособный вариант попадает в спек, и все снова счастливы. Если же этап с проблемами совместимости искоренить насильственными методами, то мотивации в расширении спеков значительно поубавится.

Сейчас вы описали давно существующие vendor-specific OpenGL extensions. Они оговорены стандартом. Причём тут синтаксис GLSL?

И если, допустим, Линус решил все необозначенные позиксом моменты обрабатывать наиболее лояльно, то я считаю, что такому подходу можно доверять.

Последний раз когда Линус участвовал в сраче на эту тему (memcpy) он ошибался - Adobe всё же исправили баг у себя. Потому что баг был у них, а не в glibc.
Ах да, подход Линуса скорее всего был выбран для облегчения портирования ПО с других UNIX на Linux, ведь когда-то давно Линус был в этом заинтересован.

Я пофиксил ваш вопрос

... а сотрудник АМД пофиксил #version. Так что кто к чему движется - большой вопрос. strict/lazy - опять-таки, это вопрос принципиальный, и я не согласен, что эти случаи вообще имеют отношение к спеку, а значит и с вашим strict/lazy не согласен тоже.

Сейчас вы описали давно существующие vendor-specific OpenGL extensions. Они оговорены стандартом. Причём тут синтаксис GLSL?

В том то и дело, что не все оговорены, иначе бы и проблем не было. Вот инвидия взяла и расширила свою реализацию #version, а, точнее, просто проверки ставить не стала. А в стандарт не добавили пока, ну так надо чтоб добавили, и всего делов. Нет вот вам ассерты подавай, а чего б не добавить-то в стандарт? И чего б вам тулзу для проверки стандарту _на этапе отладки_ не сделать, а вы, вместо этого, требуете, чтобы вам драйвер роль валидатора исполнял? Не его это задача. Все эти проблемы - решаемы, решения известны, и ассерты - совсем не одно из них.

Последний раз когда Линус участвовал в сраче на эту тему (memcpy) он ошибался

Ещё раз: то был вопрос об undefined behavior, а мы здесь об unspecified говорим - это две огромные разницы, и в этом вся суть. Линус в ядре реализовал обработку всех неописанных позиксом случаев наиболее лояльно, а тот случай с glibc тут вообще не при чём. И Линус не ошибался, он лишь спрашивал, нафига было трогать то, что работает, и ответа не получил.

.. а сотрудник АМД пофиксил #version.

Я подробно, с примерами, расписал на прошлой странице, почему он был вынужден так поступить. Вы не забыли?

а значит и с вашим strict/lazy не согласен тоже

Ну дело ваше.

Вот инвидия взяла и расширила свою реализацию #version

Они «сузили» реализацию по сравнению с тем, что было раньше.

а, точнее, просто проверки ставить не стала. А в стандарт не добавили пока, ну так надо чтоб добавили, и всего делов.

Единственная программа, которая падала из-за этого - Metacity. Из-за одного Metacity менять спецификацию GLSL? В порядке ли вы?

И чего б вам тулзу для проверки стандарту _на этапе отладки_ не сделать, а вы, вместо этого, требуете, чтобы вам драйвер роль валидатора исполнял?

Вы, кажется, не понимаете о чём речь. Проверки из драйвера выкинуть всё равно не получится (такой необдуманный жест раскроет дыры безопасности и позволит ронять ядерный модуль) а вот усложнять его придётся. Причём непонятно, в какую сторону усложнять? Вернуть ли обработку #version в последней строке? (А почему бы и нет? Unspecified же!) И, главное, начерта?

Ещё раз: то был вопрос об undefined behavior, а мы здесь об unspecified говорим - это две огромные разницы, и в этом вся суть.

Ещё раз - всё претензии Intel, AMD, Apple, ARM, Qualcomm, Texas Instruments и Imagination Technologies. Они понимают слово «must» в том контексте не так, как вы. Почему-то. А ещё они состоят в Khronos Group. Все.
Отличающуюся от их точка зрения есть у вас и у nVidia. Больше ни у кого. Такие дела.

Я подробно, с примерами, расписал на прошлой странице, почему он был вынужден так поступить.

Если бы это было нарушением стандарта, то он бы так не поступил, ни под каким соусом. А почему он так поступил - достоверно мы не узнаем никогда.

а значит и с вашим strict/lazy не согласен тоже

Ну дело ваше.

Ну и ссылкой на авторитетный источник вы такую интерпретацию не подтвердили, равно как и я свою, но, по-моему, вполне очевидно, что и то и другое вне стандарта.

Единственная программа, которая падала из-за этого - Metacity. Из-за одного Metacity менять спецификацию GLSL? В порядке ли вы?

Да вы сами говорили, что таких случаев полно - вот и я про все говорю, а не только про конкретно этот. А в данном случае расширить уже надо не только из-за metacity, а так же по тому, что, как минимум, 2 драйвера теперь так делают, а скоро и другие подтянутся, если ещё не.

Проверки из драйвера выкинуть всё равно не получится (такой необдуманный жест раскроет дыры безопасности и позволит ронять ядерный модуль) а вот усложнять его придётся.

А где пруф? Вы видели тот патч от АМД, чтобы такое утверждать? И, разумеется, проверки надо убирать не «вообще все», чтобы драйвер падать начал. Вы уж не передёргивайте. Речь только о тех проверках, которые призваны удержать сферического коня в рамках стандарта.

Они понимают слово «must» в том контексте не так, как вы.

Во-первых, противоречия с моим пониманием тут всё равно нет. Они могут соглашаться с моим пониманием слова «must», и, тем не менее, всё-таки запретить все неописанные ситуации. Это ни чему не противоречит; я лишь говорю, что это не слишком разумно. А вот вы утверждаете, что делать наоборот - есть нарушение стандарта, и с этим я спорю. А это вы ни чем не подтвердили пока: из того, что они так делают, вовсе не следует, что они, как и вы, считают, будто инвидия нарушает стандарт. Ну это раз, а второе - это, конечно, то, что не доказано, что они и правда все так делают. Ну, тест-кейсы вас писать и проверять - не прошу, хотя пруф линк бы не помешал.

Если бы это было нарушением стандарта, то он бы так не поступил, ни под каким соусом. А почему он так поступил - достоверно мы не узнаем никогда.

Потому что пользователи год ныли «Gnome Shell падает из-за fglrx», очевидно же. Где вы были всё это время?

Ну и ссылкой на авторитетный источник вы такую интерпретацию не подтвердили, равно как и я свою, но, по-моему, вполне очевидно, что и то и другое вне стандарта.

Ну так что, считаете надо обрабатывать #version в последней строке шейдера, не выдавая ошибок?

Да вы сами говорили, что таких случаев полно - вот и я про все говорю, а не только про конкретно этот.

Смысл править спеки под людей, которые их всё равно не читают? Как не читали, так и не будут.

Речь только о тех проверках, которые призваны удержать сферического коня в рамках стандарта.

Давайте список таких проверок в студию, чего уж там. Вот например что вы думаете о pragma and extension can't be placed before «version»?

и, тем не менее, всё-таки запретить все неописанные ситуации

Наверное из вредности, или просто так, да?

Ну это раз, а второе - это, конечно, то, что не доказано, что они и правда все так делают. Ну, тест-кейсы вас писать и проверять - не прошу, хотя пруф линк бы не помешал.

Про Apple нагугливается, про AMD вы в курсе, про Intel тоже понятно (Mesa строже fglrx). Про остальных вендоров мобильной графики - им городить огород при ограниченных ресурсах железа и батарейки просто смысла нет.

Потому что пользователи год ныли «Gnome Shell падает из-за fglrx», очевидно же. Где вы были всё это время?

Этого не достаточно, чтобы пойти против стандарта. Его мнение явно было чем-то серьёзно смягчено - как думаете, чем? Он сделал это изменение вообще без лишних слов и колебаний. Он не сказал «чёрт, вот козлы, придётся против спека из-за них пойти».

Ну так что, считаете надо обрабатывать #version в последней строке шейдера, не выдавая ошибок?

Да без понятия: а инвидия это делает? Это было бы кому-нить полезно? Это потребует лишь минимального изменения в драйвере? Если все ответы «Да», то я не против. :) Опять же, не привязывайтесь к специфике данного случая: вы сами давали ссылку на слешдот, где эта «проблема» описывалась в общем - вот с неё спор и разгорелся, а теперь вы пытаетесь к деталям всё свести. Не надо было тогда ту ссылку давать.

Наверное из вредности, или просто так, да?

Не могу сказать точно, но, тем не менее, вижу, что совершенно легко и непренуждённо меняют это, как только вопросы появляются. Может, им так было легче драйвер писать, хотя и это не очевидно. Как узнать? А как узнать их понимание слова «must», и их мнение на то, нарушает ли инвидия спек? Видимо, нам это узнать не суждено. Между тем, выяснить истину можно и не зная их мнение: вот, к примеру, мы имеем шейдер вне стандарта, а вы рассуждаете про lazy интерпретацию стандарта - вот это не логично совершенно. И тд. У меня нет претензий к ним - они своё понимание мне не излагали. К вам - есть. :)

Он сделал это изменение вообще без лишних слов и колебаний.

Ага, месяц «не колебался». И до этого год «не колебался». За это время, в течении которого он «не колебался», Gnome Shell 3.0 успел добраться до релиза 3.4.1. Смешно читать, ей богу. Если вы за это время даже не поинтересовались, о чём спор, воздержитесь от подобных заявлений.

Да без понятия: а инвидия это делает?

Это видимо у вас главный критерий.

Это было бы кому-нить полезно?

Конечно же! Например людям, которым лень читать и соблюдать спецификации.

Это потребует лишь минимального изменения в драйвере?

Даже минимальное изменение требует ресурсов для поиска регрессий.

Опять же, не привязывайтесь к специфике данного случая

Я не привязываюсь. Вы пишите Речь только о тех проверках, которые призваны удержать сферического коня в рамках стандарта. Так давайте изучим эту идею на каком-нибудь примере. Вот вы например проигнорировали вопрос о pragma and extension can't be placed before «version» из моего предыдущего сообщения. Ну так какой ваш итоговый вердикт?

вы сами давали ссылку на слешдот, где эта «проблема» описывалась в общем

Это не является проблемой только для CUDA-разработчиков, которым нужно забацать визуализацию для своего проекта. Тогда им можно наплевать на стандарт и писать рендер под блоб nVidia.

Не надо было тогда ту ссылку давать.

Спасибо за то, что проинформировали. Постараюсь впредь воздержаться от столь глупых поступков.

совершенно легко и непренуждённо меняют

Уже опровергнуто в начале этого сообщения, а значит дальнейшие логические построения из последнего абзаца вашего сообщения рушатся.

вот, к примеру, мы имеем шейдер вне стандарта, а вы рассуждаете про lazy интерпретацию стандарта - вот это не логично совершенно

Ну вот где вы увидели «lazy интерпретацию стандарта»? Не выдумайте. Вы спорите с самим собой сейчас.

У меня нет претензий к ним - они своё понимание мне не излагали.

Я «изложил» своё понимание вам не больше и не меньше, чем это сделал Пьер или комментатор со Слэшдота - в открытой форме на публичном ресурсе. Однако, претензии у вас есть только ко мне. Нелогично.

(: Не любят они ЛОР, однако: http://dev.pixellight.org/forum/viewtopic.php?f=6&t=531#p1648

Ага, месяц «не колебался». И до этого год «не колебался». За это время, в течении которого он «не колебался», Gnome Shell 3.0 успел добраться до релиза 3.4.1. Смешно читать, ей богу.

Притягиваете факты за уши? Там от него всего 2 сообщения, и последнее начинается словами «спасибо за стек трейс, теперь мне всё понятно, всё сделаю». И не делайте вид, что вы этого там не заметили.

Да без понятия: а инвидия это делает?

Это видимо у вас главный критерий.

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

Даже минимальное изменение требует ресурсов для поиска регрессий.

Ну, можно и изначально, как это делает инвидия, просто лишних проверок не ставить. А теперь-то да, теперь им пришлось чуток доработать. Уверен, что самую малость.

Так давайте изучим эту идею на каком-нибудь примере.

Который кем-то реализован и кем-то опробован - ок.

Уже опровергнуто в начале этого сообщения

Нет.

Ну вот где вы увидели «lazy интерпретацию стандарта»? Не выдумайте.

Полагаю, что это - придирка к словам.

Я «изложил» своё понимание вам не больше и не меньше, чем это сделал Пьер или комментатор со Слэшдота

Ничего Пьер не излагал - он не давал свою оценку тактике инвидии, не говорил ни про какие нарушения, про strict/lazy, и тд. К его словам ни единой претензии, а вот к слешдотовцу - да, согласен.

Однако, претензии у вас есть только ко мне. Нелогично.

Фраза вырвана из контекста. Я говорил, что у меня нет претензий к инженерам, мнение которых мы узнать не сможем, а к вам - есть. А вы слешдотовца приплели, но это как и со спеком: я его в той фразе просто не упоминал, так что нельзя было сделать вывод, что к нему у меня претензий нет. Точно так же вы и из спеков выводы делаете на то, что там не написано.

Притягиваете факты за уши? Там от него всего 2 сообщения

И срок между ними - месяц (не делайте вид, что вы этого там не заметили). Уже одно это не позволяет написать Он сделал это изменение вообще без лишних слов и колебаний.

Разумеется, ведь критерии просты: кто-то сделал расширение, юзерам жутко понравилось, сочли полезным

Всё это не имеет отношения к Metacity.

По тому я и не собираюсь рассматривать ваши примеры: я понятия не имею, кто их испытывал, и кому они хоть немного нужны.

Это про vendor-specific OpenGL extensions и не имеет отношения к GLSL. Вопрос был про GLSL.

совершенно легко и непренуждённо меняют

Уже опровергнуто в начале этого сообщения, а значит дальнейшие логические построения из последнего абзаца вашего сообщения рушатся.

Нет.

Не нет, а да. Metacity падал на fglrx с шестого апреля 2011 год по 29 июня 2012 года. О проблеме AMD было известно как минимум с ноября 2011 года (выпуск поддерживаемого AMD дистрибутива openSUSE 12.1, который проходит внутреннее тестирование наравне с Ubuntu и коммерческими дистрибутивами Linux; openSUSE 12.1 был первой версией openSUSE с Gnome Shell). Так что хватит фантазировать про лёгкое и непринуждённое изменение. Смотрите в лицо фактам - им было нечего править всё это время, потому что на их стороне багов не было.

Полагаю, что это - придирка к словам.

Полагаю, что вы до сих пор не поняли о чём я говорил, упоминая lazy и strict. Точно так же вы и из спеков выводы делаете на то, что там не написано.

он не давал свою оценку тактике инвидии

Не имеет права. Даже сотрудник PixelLight по ссылке выше пишет Sadly, some shader compilers are far too tolerant and do not blame violations of the official GLSL specification политкорректно не упоминая, кого он имеет ввиду. Выглядит почти как «не будем говорить кто, хотя это был слоненок».

не говорил ни про какие нарушения

Он говорил языком фактов: цитата из спека и описание поведения драйвера nVidia.

а вот к слешдотовцу - да, согласен

так что нельзя было сделать вывод, что к нему у меня претензий нет

Ну так есть, или нет? Если есть, чего вы ждёте?

Точно так же вы и из спеков выводы делаете на то, что там не написано.

Напомню, что эти же выводы делает ещё семь GPU-вендоров. Их выводы против выводов одного (делающего всё для vendor lock-in) поведение которого совсем не радует например разработчиков обсуждаемого программного продукта.

Не понятно о чем речь. Проект-то под GPL. <script>alert(«Hello World!»)</script>

Я ошибся веткой

Уже одно это не позволяет написать Он сделал это изменение вообще без лишних слов и колебаний.

Ничего подобного, он до стек трейса вообще не знал, чо происходит. А потом сразу исправил.

Всё это не имеет отношения к Metacity.

Зато, имеет отношение к ссылке на слэшдоте. Данная конкретная трабла с Metacity меня не так уж и волнует, в отличии от того коммента, и с ним вы тоже согласны были вполне.

Это про vendor-specific OpenGL extensions и не имеет отношения к GLSL. Вопрос был про GLSL.

И даже коммент на слешдоте был про него?

Полагаю, что вы до сих пор не поняли о чём я говорил, упоминая lazy и strict.

Ну так расскажите. Я не телепат.

Он говорил языком фактов: цитата из спека и описание поведения драйвера nVidia.

Я уже говорил, что спек описывает, как должна вести себя прога, а не драйвер. Это - его область применения. Вообще, в OpenGL спеке есть главы и for implementors, но цитата была явно не из них. И здесь _прога_ вышла за рамки спека, а что делать драйверу в этом случае - там не написано, и он не говорил. Не приписывайте ему свои домыслы. То, что он объяснил поведение драйвера инвидии, не означает, что он с ним не согласен. А потом он и в АМД так же точно сделал, и, таки, без колебаний - на этом настаиваю, не притягивайте факты за уши. Он до этого не знал, где проблема.

Ну так есть, или нет? Если есть, чего вы ждёте?

Претензии к слешдотовцу конечно есть, и, соответственно, к вам, как к человеку, ссылающемуся на него, как на истину в высшей инстанции. Я лишь вам пытаюсь доказать, что он сказал фигню, и ничего больше я вам здесь доказать не пытаюсь. Конкретно проблема Metacity меня гораздо меньше интересует, и она сильно специфична, чтобы в общем о ней судить.

Напомню, что эти же выводы делает ещё семь GPU-вендоров.

Вы не знаете, какие выводы они делают, и почему реализовыывают неописанное поведение так, или иначе. Вопрос не в этом, а в том, является ли инвидиевская реализация каким-либо нарушением, или не является. Вот чёткий и ясный вопрос, и мой ответ на него - нет.

А потом он и в АМД так же точно сделал, и, таки, без колебаний - на этом настаиваю, не притягивайте факты за уши. Он до этого не знал, где проблема.

Ничего подобного, он до стек трейса вообще не знал, чо происходит.

Совсем, совсем не знал.

Зато, имеет отношение к ссылке на слэшдоте.

И даже коммент на слешдоте был про него?

Хорошо, с другой стороны: какое отношение vendor-specific OpenGL extensions имеют к комментарию на Слэшдоте?

Ну так расскажите. Я не телепат.

Цитата разработчика PixelLight из предыдущего сообщения ни на какие мысли не наводит?

То, что он объяснил поведение драйвера инвидии, не означает, что он с ним не согласен.

Ха, наверное поэтому Catalyst строже драйвера nVidia?

Претензии к слешдотовцу конечно есть, и, соответственно, к вам, как к человеку, ссылающемуся на него, как на истину в высшей инстанции. Я лишь вам пытаюсь доказать, что он сказал фигню, и ничего больше я вам здесь доказать не пытаюсь.

Докажите мне, что один из разработчиков PixelLight тоже сказал фигню.

Вы не знаете, какие выводы они делают, и почему реализовыывают неописанное поведение так, или иначе.

Зато знаю, почему именно так реализовано поведение у nVidia. По этому пункту разногласий, насколько я помню, нет?

Вопрос не в этом, а в том, является ли инвидиевская реализация каким-либо нарушением, или не является.

Вопрос в понимании слова «must» из спека.

Совсем, совсем не знал.

Нет, просто, видимо, подозревал, и решил спросить у людей, наблюдают ли они такое-то сообщение. Как только ему ответили, и приложили стектрейс, он _сразу_ всё исправил. Он не виноват, что на его простейший вопрос чувак ответил только через месяц.

Хорошо, с другой стороны: какое отношение vendor-specific OpenGL extensions имеют к комментарию на Слэшдоте?

Что вы называете vendor-specific OpenGL extensions? На слешдоте сказано следующее:

With Nvidia cards you can pretty much call any old combination of GL functions, and something will appear on screen.

Цитата разработчика PixelLight из предыдущего сообщения ни на какие мысли не наводит?

Он про GLSL говорил, а слешдотовец - про обычный OpenGL.

Ха, наверное поэтому Catalyst строже драйвера nVidia?

Опять вы всё за уши притягиваете и додумываете. Он мог быть согласен с тем, что делает драйвер инвидии, и, тем не менее, сделать по-другому, всилу каких-то неизвестных нам причин. Он мог быть и не согласен с тем, как ведёт себя драйвер инвидии, но не по причине нарушения спеков, а по каким-то неизвестным нам причинам. Он ничего этого не сказал! Нельзя приписывать всюду свои домыслы, и ссылаться на это, как на что-то доказанное. При всём уважении, вы делаете это постоянно.

Зато знаю, почему именно так реализовано поведение у nVidia. По этому пункту разногласий, насколько я помню, нет?

Да ничего вы не знаете - вы всегда ссылаетесь на собственные домыслы, но разногласий по этому пункту нет, так как он мало интересен. Они могли это сделать по совершенно разным соображениям, от «нафига ставить лишние проверки» до «хитроумный заговор по ввержению юзеров в вендор-локин». И знать вы этого не можете никак.

Вопрос в понимании слова «must» из спека.

В частности, но не только. В понимании применимости спека тоже, к примеру, этот «must» там вовсе не для драйвера, так как драйвер эти действия не выполняет, которые под must должны подпадать, следовательно must там совершенно не для него. В понимании того, на каком этапе и какими средствами надо производить валидацию кода (на этапе исполнения или отладки, средствами тулзы или драйвера), и тд - короче, тут разногласий на кучу пунктов, а вовсе не только по пониманию слова must. И если даже я не могу доказать вам верность своего понимания этого вопроса, то хотя бы доказать, что всё, что вы приводите в качестве доказательств, на самом деле лишь основано на личных домыслах - я, в принципе, могу, и пытаюсь. :)

Нет, просто, видимо, подозревал, и решил спросить у людей, наблюдают ли они такое-то сообщение.

Вероятно ожидал, что люди сообразят оформить багрепорт в багтрекер Гнома. Не сообразили. Всё как обычно - пользователи даже не допускают мысли о том, что проблема может быть не в fglrx, если она не воспроизводится на nVidia.

Как только ему ответили, и приложили стектрейс, он _сразу_ всё исправил.

Он же написал, что воспроизвёл падение ранее - думаете, у него своего backtrace не было до этого? Использовать слово «исправил» в отношении подстановки костыля под кривой софт в драйвере, пожалуй не совсем корректно, как считаете?

Что вы называете vendor-specific OpenGL extensions?

То же, что и все: NV_shader_buffer_load, AMD_vertex _shader_layer, NV_texture _multisample, AMD_depth _clamp_separate и т.д. Вы же зачем-то пытаетесь применять логику vendor-specific OpenGL extensions к GLSL.

Это и есть обработка ситуаций за рамками стандарта OpenGL. Это не то же самое, что официальные vendor-specific OpenGL extensions, и если вы про них, то они тут вообще не при чём.

О чём я сразу же и написал, хотя вы похоже тогда не заметили это.

Он про GLSL говорил, а слешдотовец - про обычный OpenGL.

GLSL расшифровывается как OpenGL Shading Language. Т.е. у nVidia своеобразный взгляд на OpenGL в целом, а не на OpenGL API или GLSL в частности. Так что эти два отзыва вполне дополняют друг друга и создают цельную картину.

И если даже я не могу доказать вам верность своего понимания этого вопроса, то хотя бы доказать, что всё, что вы приводите в качестве доказательств, на самом деле лишь основано на личных домыслах - я, в принципе, могу, и пытаюсь. :)

Например очень сложно догадаться в случае Sadly, some shader compilers are far too tolerant and do not blame violations of the official GLSL specification о ком же идёт речь. Столько много вариантов. Нужно домысливать изо всех сил :)

Претензии к слешдотовцу конечно есть, и, соответственно, к вам, как к человеку, ссылающемуся на него, как на истину в высшей инстанции. Я лишь вам пытаюсь доказать, что он сказал фигню, и ничего больше я вам здесь доказать не пытаюсь.

Докажите мне, что один из разработчиков PixelLight тоже сказал фигню.

Опять вы всё за уши притягиваете и додумываете. Он мог быть согласен с тем, что делает драйвер инвидии, и, тем не менее, сделать по-другому, всилу каких-то неизвестных нам причин. Он мог быть и не согласен с тем, как ведёт себя драйвер инвидии, но не по причине нарушения спеков, а по каким-то неизвестным нам причинам. Он ничего этого не сказал! Нельзя приписывать всюду свои домыслы, и ссылаться на это, как на что-то доказанное. При всём уважении, вы делаете это постоянно.

Вы пытаетесь увести аргументы, противоречащие вашей точке зрения в область «недоказанного», хотя их суммарное количество уже таково («must» в спеке, соответствующая реализация в драйверах подавляющего большинства вендоров (не только в драйверах - в QGLShader тоже) и недовольство своеобразной реализацией nVidia со стороны девелоперов) что нет смысла дальше писать про неизвестные причины, домыслы и прочее.

Они могли это сделать по совершенно разным соображениям, от «нафига ставить лишние проверки» до «хитроумный заговор по ввержению юзеров в вендор-локин». И знать вы этого не можете никак.

Вы сами же сказали о nVidia: конкурентная борьба, ничего особенного.

Он же написал, что воспроизвёл падение ранее

Да где?? Он написал, что видел в соседнем триде вот такое-то сообщение, и спросил, а не видели ли такое же в этом триде. Где он говорит, что у него уже был стектрейс? И к чему тогда все его «thanks for the stack traces. they were really useful.»? Это, типа, он так глумится чтоль?

Например очень сложно догадаться в случае Sadly

Нет, здесь не сложно... Но он говорит про GLSL. Я бы не хотел касаться этой темы - обсуждать слешдотовский коммент можно и без GLSL, а никаких данных о терминологии и области применимости спека GLSL у меня нет.

GLSL расшифровывается как OpenGL Shading Language. Т.е. у nVidia своеобразный взгляд на OpenGL в целом, а не на OpenGL API или GLSL в частности. Так что эти два отзыва вполне дополняют друг друга и создают цельную картину.

Но спеки у них отдельные, и говорить что-либо о трактовке спека GLSL - не беру на себя смелость, уж извините. :)

Докажите мне, что один из разработчиков PixelLight тоже сказал фигню.

Не могу. Он про GLSL говорил, я пасс. Могу только про коммент со слешдота говорить - с него спор и пошёл. Спеки разные - зачем обсуждать сразу два. Лично у меня есть сомнения, что оба эти спека писались в одном ключе, с единой терминологией, и тд.

недовольство своеобразной реализацией nVidia со стороны девелоперов

Есть ли примеры помимо GLSL, при чём от девелоперов, ну если не драйверов, то, хотя бы, чего-то очень существенного? У вас есть только один пример, но он касается GLSL, и разработчик не драйвера, а PixelLight. Да, это лучше, чем ничего, и всё же маловато. А вот про выводы на счёт «must» я точно не согласен, по тому, что причин так реализовывать у них и правда мог быть миллион, и их можно даже навскидку придумывать. Ну хотя бы чтоб на QA сэкономить. И про ембеддед, вы сами сказали, что им не с руки было бы делать иначе - я согласен на все сто. Ну а уж те аргументы, что, яко бы, Пьер так высказался - это уж извините-подвиньтесь, тут вы радикально всё за уши притянули, как по мне. По тому не согласен, что вы берёте количеством косвенных аргументов. Один косвенный аргумент на тему GLSL - да, имеет место, и только то.

Вы сами же сказали о nVidia: конкурентная борьба, ничего особенного.

Это высказывание больше к результату относилось. Да, в результате такой реализации, обострилась конкурентная борьба, но я не рискну утверждать, что это и было изначальной их мотивацией - слишком много других причин можно влёт напридумывать.

Докажите мне, что один из разработчиков PixelLight тоже сказал фигню.

Кстати, ещё раз перечитав его высказывание... а в чём, собственно, сыр-бор? Ну он говорит, что некоторые компиляторы относятся снисходительно к нарушениям стандарта - это очевидная истина. Я как-то поддался вашему моральному давлению, и прочёл это как и вы, что «некоторые компиляторы нарушают стандарт», а нифига! Не сказал он так. Он лишь сказал, что они лояльны к нарушениям спека, ну так это мы все и так знаем. Выходит, аргументов с вашей стороны - ноль (это не наезд, а коррекция моего предыдущего высказывания о том, что один аргумент есть). Вы чуток надавили на меня, и я тоже стал неправильно всё читать. :) Нет уж, дудки. Ну и он ещё сказал, что ему это поведение мешает отлаживаться - с этим тоже не поспоришь, мешает. Хотя, гораздо больше ему мешает то, что он ленится валидатор написать.

Да где?? Он написал, что видел в соседнем триде вот такое-то сообщение, и спросил, а не видели ли такое же в этом триде. Где он говорит, что у него уже был стектрейс?

Не из воздуха же он взял цитату из backtrace до выкладывания backtrace пользователем.

Ну и он ещё сказал, что ему это поведение мешает отлаживаться - с этим тоже не поспоришь, мешает.

И слэшдотовцу мешает... вот такая вот пичалька.

Хотя, гораздо больше ему мешает то, что он ленится валидатор написать.

Нет смысла, ведь можно просто взять не нвидию.

А вот про выводы на счёт «must» я точно не согласен, по тому, что причин так реализовывать у них и правда мог быть миллион, и их можно даже навскидку придумывать.

И из этого миллиона вы не приемлите лишь одну, причём самую очевидную - простейшее толкование слова «must» из спецификации, всеми вендорами, кроме nVidia.

но я не рискну утверждать, что это и было изначальной их мотивацией

Так много причин, с учётом общей стратегии компании... какую же выбрать?

Не из воздуха же он взял цитату из backtrace до выкладывания backtrace пользователем.

Не из воздуха - из другого трида багзиллы. О чём и написал. Видите, сколько с вашей стороны притягиваний за уши, даже относительно этого небольшого его письма? :)

И слэшдотовцу мешает... вот такая вот пичалька.

Слешдотовец хает драйвер инвидии при этом, а разработчик пиксельлайта - нет, просто констатирует факты, суждений не делает. Так что к нему претензий нет.

Нет смысла, ведь можно просто взять не нвидию.

Вы что, всерьёз думаете, что, даже если драйвер утонет в ассертах, это заменит нормальный валидатор кода? Вот сколько в glibc ни ставят проверок на всякие double-free, а valgrind пока ни кто не отменял - с чего бы это? Да с того, что валидатор лучше любых ассертов в сто раз.

И из этого миллиона вы не приемлите лишь одну, причём самую очевидную - простейшее толкование слова «must» из спецификации, всеми вендорами, кроме nVidia.

Да, не приемлю, так как его область применения на драйвер не распространяется: он для юзерского кода. Но я могу согласиться с его косвенным влиянием: разработчики драйвера решили подсобить юзерам с отладкой, добрые дяди, так сказать.

Так много причин, с учётом общей стратегии компании... какую же выбрать?

Да не столь важно, ну пускай будет маркетинг. Точно-то мы не знаем всё равно.

даже если драйвер утонет в ассертах, это заменит нормальный валидатор кода?

Оговорюсь, что имею в виду OpenGL API. Что касается GLSL - там, _возможно_, драйвер и может заменить валидатор в каком-то плане. По тому, всё таки, высказывание разработчика пиксельлайта лучше бы за скобками оставить: слишком разные подходы.

Не из воздуха - из другого трида багзиллы. О чём и написал. Видите, сколько с вашей стороны притягиваний за уши, даже относительно этого небольшого его письма? :)

Повеселили. Вы программист, или где? С понятием «поток» знакомы? (И я даже не говорю о том, что отсутствие упоминания этой ошибки в других тикетах багтрекера проверяется гуглом.)

Слешдотовец хает драйвер инвидии при этом, а разработчик пиксельлайта - нет, просто констатирует факты, суждений не делает. Так что к нему претензий нет.

Т.е. претензия к форме, но не содержанию, так как по сути смысловая часть у этих сообщений об одном.

Вы что, всерьёз думаете, что, даже если драйвер утонет в ассертах, это заменит нормальный валидатор кода?

Зачем топить? Достаточно того, чтобы код, соответствующий спекам работал, а несоответствующий - нет, и у всех, кроме nVidia, реализовано именно так.

Повеселили. Вы программист, или где? С понятием «поток» знакомы?

Ах вот как вы решили всё обставить: «failure reported in another thread», оказывается, теперь не к баг-репорту относится... Ну ладно, продолжайте такую логику, и опишите в её рамках его дальнейшие высказывания, типа «thanks for the stack traces. they were really useful». А ещё, советую обратить внимание, как другие участники дискуссии эту его фразу восприняли: «As for a rapid way to find the bug, it's easily found by opening up a few programs that one would use on a desktop». То есть люди начали ему советовать, как ему лучше это воспроизвести, стали стек-трейсы давать, потом он их поблагодарил и всё исправил, а вы взяли и перевели это так, будто у него всё заранее было... Он, видимо, там веселится и развлекается во всю, потешаясь над юзерами, ага. :) Вам самому не смешно такие натяжки делать? Да и пробуксует такая логика по-любому, когда второе его письмо трактовать станете.

Т.е. претензия к форме, но не содержанию

Нет. Слешдотовец сказал следующее:

Unlike Nvidia cards they actually implement the GL spec to the letter.

и у всех, кроме nVidia, реализовано именно так.

Уже нет, сами видели. Да и то, что у кучи вендоров это так, я «принял» без доказательств, чтобы вам жизнь не усложнять.

Повеселили. Вы программист, или где? С понятием «поток» знакомы?

И, в догонку, вы думаете, на багзилле одни программисты сидят? Сомневаюсь, и зачем ему было вообще там про thread говорить, в значении «поток»? Во-первых, никто бы не понял, а во вторых - по-просту не к месту. Какая разница, какой трид ошибку напечатал? В общем...

И я даже не говорю о том, что отсутствие упоминания этой ошибки в других тикетах багтрекера проверяется гуглом.

Вот: http://ati.cchtml.com/show_bug.cgi?id=408

Утёрлись? :)

Утёрлись? :)

(Внимательно смотрим на даты.) Ну вот вы и доказали, что backtrace у него были как минимум за два месяца до внесения изменений, которые он по вашим словам сделал «без колебаний». Спасибо за то, что перехитрили сами себя. Утёрлись? :)

То есть он сделал прямое утверждение, что инвидия не чётко следует стандарту.

Так и есть, и выше мы это уже обсудили.

Уже нет, сами видели.

Это исключение, не правило, как у nVidia.

Спасибо за то, что перехитрили сами себя.

Я, если вы не заметили, не хитрил, а методично опровергал все ваши аргументы. Для начала, вам бы следовало признать, что несли чушь на счёт thread, и вообще всего, что было связано с письмами Пьера.

А то, что я, яко бы, доказал - это вы опять виляете, в очередной раз, утомительно. :) Я уже говорил: в том, триде он показал логи из этого трида, и спросил, «граждане, не видели ли вы такого и тут?». Ему ответили - «да сэр, видели, и вот вам стек трейсы», а он «ну гут, ща пофиксим», и всё!

Так и есть, и выше мы это уже обсудили.

Что так и есть то? Я вам доказал, надеюсь, что ни кто, кроме слэшдотовца и вас, не утверждал, что инвидия нарушает спеки? Доказал или нет? Дальнейшее можно и не доказывать, главное, чтобы вы остались с ним наедине, и задумались о жизни. :)

Я, если вы не заметили, не хитрил, а методично опровергал все ваши аргументы. Для начала, вам бы следовало признать, что несли чушь на счёт thread, и вообще всего, что было связано с письмами Пьера.

Для начала вам следовало бы перечитать страницу и признать всё то, что вас следовало бы признать. Мне делать это лень, и требовать с вас что-либо - тоже. Ну или можете багтрекер почитать, может ещё что-нибудь интересное откопаете.

Я уже говорил: в том, триде он показал логи из этого трида, и спросил, «граждане, не видели ли вы такого и тут?». Ему ответили - «да сэр, видели, и вот вам стек трейсы», а он «ну гут, ща пофиксим», и всё!

При том, что в AMD воспроизвели это падение после релиза openSUSE 12.1 в ноябре (т.к. openSUSE находится в списке официально поддерживаемых дистрибутивов) при том что лично Пьер видел соответствующие backtrace в феврале, и при том, что он снова увидел аналогичное сообщение об ошибке в марте, вы продолжаете настаивать на том, что он ждал апрельские backtrace чтобы внести изменения. Ну продолжайте, коли неймётся.

Что так и есть то? Я вам доказал, надеюсь, что ни кто, кроме слэшдотовца и вас, не утверждал, что инвидия нарушает спеки? Доказал или нет?

Вы доказали, что nVidia не нарушает спеки если к слову «must» придумать мудрёное толкование.

Мне делать это лень, и требовать с вас что-либо - тоже.

Дело даже не в том, что вы нужный трид не удосужились отыскать - лень есть лень, и я сделал это за вас, нет проблем. Вопрос в том, как клёво вы с переводом письма извернулись в плане thread, чтобы меня обдурить - вот за это реальный зачот и аплодисменты. :) И это бы вам следовало признать за чушь, ну да ладно, зато оригинально было.

при том что лично Пьер видел соответствующие backtrace в феврале

А давно ли лог у вас стал стектрейсом? Стектрейс ему дал Ken P. 2012-04-22 18:02:57 CDT. По стектрейсу он, предположительно, нашёл текст соответствующего шейдера, и разобрался в вопросе. Заметьте, что в баге 408 он никаких комментариев не дал, когда увидел лог. Если чел молчит, значит, ему не хватает данных, значит он ещё тогда не видел сам код шейдера, и не знал, откуда ошибка. Потом он спросил про неё в другом триде, чтобы собрать больше инфы, ну и собрал. Ваши конспирологические теории о том, что он стебался над юзерами, не выдерживают ни малейшей критики.

Вы доказали, что nVidia не нарушает спеки если к слову «must» придумать мудрёное толкование.

Это не предел мечтаний - на доказательство того, что ни кто, кроме вас и слешдотовца, не делал неверных утверждений, данных вполне достаточно. И вам от этого не скрыться и не спрятаться.

чтобы меня обдурить

Однако же, высокого вы о себе мнения.

И это бы вам следовало признать за чушь, ну да ладно, зато оригинально было.

Ну вот вы например пишите Где он говорит, что у него уже был стектрейс? и сами же приводите ссылку на багрепорт, в котором есть ссылки на backtrace падений. Не «говорил», но как видите, «стектрейс был». Когда вы это признаете? Да никогда.

А давно ли лог у вас стал стектрейсом?

С тех самых пор, как вы перестали читать багрепорты, на которые сами же ссылаетесь. Как-то так.

ни кто, кроме вас и слешдотовца, не делал неверных утверждений

Опять же, претензия к форме («заявление») а не содержанию (реализация) - ни у кого, кроме nVidia не было такой реализации #version. Кстати, в копилку вендоров с нормальным пониманием «must» - виртуальный видеодрайвер Parallels.

Однако же, высокого вы о себе мнения.

Вы всё ещё на thread настаиваете чтоль, я не понял?

Не «говорил», но как видите, «стектрейс был». Когда вы это признаете? Да никогда.

Где и у кого был? Если вы про те ссылки на редхатовскую багзиллу, где тонны спама и трейсы от abrt без дебагинфы, то всё, что он сказал на них, было " Looking at some stack trace, it looks like the crash happens inside glib, and not coming from the display driver: do you agree ?" Это, конечно, по-вашему, означает, что проблему он идентифицировал? Наверное, потом он ещё и пофиксил glib. :)

Опять же, претензия к форме («заявление») а не содержанию (реализация)

Претензия к выводам! Слэшдотовские выводы, которые вы усердно пропагандируете, заключались в том, что инвидия не по спекам сделала драйвер, вот и всё. За это я вам тут всё докажу, и с рук вам эти обвинения в их адрес не сойдут, так то.

Вы всё ещё на thread настаиваете чтоль, я не понял?

Нет, меня удивляет формулировка «чтобы меня обдурить» на которую я отвечаю Однако же, высокого вы о себе мнения.

Если вы про те ссылки на редхатовскую багзиллу, где тонны спама и трейсы от abrt без дебагинфы

Уже не важно. Связался с Пьером Джаспером по поводу этого несчастного шейдера - c Clutter 1.8.4+ проблем с ним быть не должно. Уже отписал об этом Пьеру Будье, но к сожалению, до завершения сроков поддержки Ubuntu 11.10 (Clutter 1.8.0) и openSUSE 12.1 (Clutter 1.8.2) вернуть старую реализацию нельзя.

Претензия к выводам!

Ну вот и разработчики, драйверов, тулкитов и виртуальных машин, тоже сделали вполне конкретные выводы из спецификации.

Слэшдотовские выводы, которые вы усердно пропагандируете

И которые подтверждаются реализациями OpenGL в целом, реализациями разбора #version в частности, и вектором nVidia в отношении реализации разбора #version (от lazy в предыдущих версиях драйвера к strict; из пункта"a" следует, что движение не завершено). Вектор nVidia вы упорно игнорируете, и как вы говорите, вам следовало бы это признать.

Слэшдотовские выводы, которые вы усердно пропагандируете, заключались в том, что инвидия не по спекам сделала драйвер, вот и всё.

Именно так. Всё остальные понимают слово «must» не так, как вы и nVidia.

За это я вам тут всё докажу, и с рук вам эти обвинения в их адрес не сойдут, так то.

А потом объявите охоту за разработчиками piglit, ггг. У вас же есть карточка nVidia? Прогоните на ней piglit с последним блобом да почитайте отчёт. Откроете для себя много нового в отношении разницы понимания спеков nVidia и всеми остальными.

Нет, меня удивляет формулировка «чтобы меня обдурить»

Больше никак не смог объяснить подобный выкрутас, особенно в контексте ваших остальных многочисленных притягиваний за уши.

Ну вот и разработчики, драйверов, тулкитов и виртуальных машин, тоже сделали вполне конкретные выводы из спецификации.

Это мы обсуждали много раз: тут совершенно ничего не доказано. А вот то, что они это _сразу_ изменили, без протестов и попыток сделать что-либо другое, и даже без негативных коментов в адрес инвидии - о многом говорит. А то, что вы кому-то отписали - ну так посмотрим. Что-то мне подсказывает, что ни сейчас, ни потом, они назад это не изменят, сколько бы вы им ни писали. Так как, по-просту, в этом нет необходимости.

Именно так. Всё остальные понимают слово «must» не так, как вы и nVidia.

Однако все ваши попытки выдать слова других за такое понимание, оказались смехотворными. Вот почему бы? Нет ни одного доказательства того, как они его понимают, ни одного. Только ваши домыслы. А мне уже гораздо важнее доказать, что, кроме вас и слэшдотовца, никто чушь не нёс. На это данных хватит, а остальное доказать не удастся, но там я хотя бы все ваши доводы опроверг.

У вас же есть карточка nVidia?

Никогда их карточки не покупал и не использовал. У меня радеон. Опять сделали лишний домысел. :)

совершенно ничего

Однако все ваши попытки выдать слова других за такое понимание, оказались смехотворными. Вот почему бы? Нет ни одного доказательства того, как они его понимают, ни одного. Только ваши домыслы.

Закупайтесь железом, и вперёд - тестировать. Не можете, не хотите - доказательства уже есть в Гугле.

А мне уже гораздо важнее доказать, что, кроме вас и слэшдотовца, никто чушь не нёс.

Берите блоб nVidia, прогоняйте piglit - доказывайте.

А вот то, что они это _сразу_ изменили

Я таки уже устал повторять, что openSUSE 12.1 тестировали ещё в ноябре. Багрепорты по факту падения есть ещё за сентябрь.

без протестов

Это не опенсорс - дебаты никто никогда не устраивает.

и попыток сделать что-либо другое

Я уже писал на первой странице, во что для AMD выливается «что-либо другое».

и даже без негативных коментов в адрес инвидии - о многом говорит.

Ну с чего, с чего вы взяли, что сотрудник AMD на публичном ресурсе, да ещё и с ящика @amd.com, может начать хаять nVidia в открытую?

Что-то мне подсказывает, что ни сейчас, ни потом, они назад это не изменят, сколько бы вы им ни писали. Так как, по-просту, в этом нет необходимости.

Напомню в очередной раз, что например nVidia сделали свою реализацию более строгой (пункты «b» и «c» которых раньше не было.) Вектор nVidia вы упорно игнорируете, и как вы говорите, вам следовало бы это признать. С какого потолка вы взяли то, что AMD не могут вернуть более строгую реализацию?

Никогда их карточки не покупал и не использовал. У меня радеон. Опять сделали лишний домысел. :)

У меня вот карточки разных вендоров. Что такого вы там разглядели в предположении наличия у вас GeForce?

Берите блоб nVidia, прогоняйте piglit - доказывайте.

Мне каежтся, я и без тестирования доказал уже, что ни кто, кроме слэшдотовца и вас, про нарушение спеков драйвером не говорил и не намекал. Если вы ещё не отказались от своих конспирологических теорий о том, что Пьер, яко бы, стебался над юзерами, то я уже не знаю, что можно сделать... Я вообще не понимаю, как подобные натяжки можно использовать, как яко бы доказанные аргументы.

Я таки уже устал повторять, что openSUSE 12.1 тестировали ещё в ноябре. Багрепорты по факту падения есть ещё за сентябрь.

Ну а я вам привёл его фразу, где он говорит, что может это glib... Ну и кто из нас прав? Ответьте. :)

Это не опенсорс - дебаты никто никогда не устраивает.

... а просто-запросто нарушают спек всякими изменениями? Ну-ну. :)

Вектор nVidia вы упорно игнорируете, и как вы говорите, вам следовало бы это признать.

Игнорирую, по тому, что без пруфов. Пруфы в виде домыслов - не канают. :)

С какого потолка вы взяли то, что AMD не могут вернуть более строгую реализацию?

Это вы с какого-то потолка взяли, что, раз вы им написали, то всенепременно теперь вернут, ага. А я лишь сказал, «посмотрим».

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

Мне каежтся

Вам кажется.

Ну а я вам привёл его фразу, где он говорит, что может это glib... Ну и кто из нас прав? Ответьте. :)

Внезапно, в AMD работает больше одного человека. Это касается и разработчиков, задействованных в реализации OpenGL в Catalyst Team. Обратите внимание, что я нигде не говорил, что лично Пьер был в курсе результатов тестирования в ноябре. Опять сделали лишний домысел. :)

... а просто-запросто нарушают спек всякими изменениями? Ну-ну. :)

Я уже писал на первой странице, во что для AMD могут вылиться другие варианты.

Игнорирую, по тому, что без пруфов. Пруфы в виде домыслов - не канают. :)

Закупайтесь железом, и вперёд - тестировать. Не можете, не хотите - доказательства уже есть в Гугле.

Это вы с какого-то потолка взяли, что, раз вы им написали, то всенепременно теперь вернут, ага.

Раньше было одно приложение, которому workaround был необходим, сейчас - ноль. Смысла оставлять workaround в драйвере - столько же.

Вам кажется.

Тогда прямой вопрос: КТО ещё говорил, что они нарушают спеки?

Обратите внимание, что я нигде не говорил, что лично Пьер был в курсе результатов тестирования в ноябре.

Говорили вот это:

Он же написал, что воспроизвёл падение ранее - думаете, у него своего backtrace не было до этого?

Смысла оставлять workaround в драйвере - столько же.

Какой вам нужен тайм-аут, чтобы, если это не произойдёт, признать своё поражение? :)

Внезапно, в AMD работает больше одного человека. Это касается и разработчиков, задействованных в реализации OpenGL в Catalyst Team.

О да, это гениально! Сотрудники АМД всё знали, но Пьеру не хотели подсказывать из вредности, глядя, как он в багзилле инфу выискивает месяцами. :) И даже в конце так ни в чём и не признались: он сам всё пофиксил, а они лишь многозначительно покачали головой. :))

О да, это гениально! Сотрудники АМД всё знали, но Пьеру не хотели подсказывать из вредности

Вас бросает из крайности в крайность.

Какой вам нужен тайм-аут, чтобы, если это не произойдёт, признать своё поражение? :)

Поражение в чём? Вы так говорите, будто бы обработка одного препроцессора является камнем предкновения. В спеке ещё множество мест, которые по-вашему можно считать неопределёнными, но с точки зрения разработчиков Mesa, fglrx и других драйверов - они трактуются однозначно. Даже если не затрагивать вопрос неопределённости, и взять ту же #version, в спеке GLSL английским по белому написано Version 1.10 of the language does not require shaders to include this directive, and shaders that do not include a #version directive will be treated as targeting version 1.10.
Драйвер nVidia это явное требование не выполняет, а значит имеем очередное нарушение спеков.

Жду классную историю, о том как правильно нужно читать will be treated и почему опять все, кроме nVidia, имеют вполне определённое понимание этих слов.

Тогда прямой вопрос: КТО ещё говорил, что они нарушают спеки?

Вы считаете «must» в спеке недостаточным для реализации описываемого этим словом поведения, а остальные (кроме nVidia) считают. Я считаю реализацию (точнее даже не реализацию, а общий подход к реализации) достаточным отражением точки зрения разработчиков реализации, а вы - нет. Опять же, дело ваше.

Вас бросает из крайности в крайность.

Ну так объясните наконец свои конспирологические теории.

Жду классную историю, о том как правильно нужно читать will be treated

Не дождётесь: нету у меня комментов по поводу GLSL. Слэшдотовец говорил не про него. По поводу GLSL, идея была лишь разоблачить все ваши конспирологические теории относительно Пьера. Надеюсь, с этим я справился: слишком мало вы стали по поводу него спорить последнее время.

Вы считаете «must» в спеке недостаточным для реализации описываемого этим словом поведения

Я считаю, что он вообще к драйверу никак не относится. Там есть главы for implementors - если must был бы оттуда, тогда да. И та трактовка слова must, которую я давал, тоже к драйверу ни малейшего отношения не имела.