From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon@freedesktop.org
Subject: [Bug 95085] Invalid sampling of second texture in fragment shader
that have two samplers with different parameters.
Date: Sat, 30 Apr 2016 01:11:16 +0000
Message-ID:
References:
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1755633103=="
Return-path:
Received: from culpepper.freedesktop.org (culpepper.freedesktop.org
[131.252.210.165])
by gabe.freedesktop.org (Postfix) with ESMTP id 1298B6E188
for ; Sat, 30 Apr 2016 01:11:16 +0000 (UTC)
In-Reply-To:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Errors-To: dri-devel-bounces@lists.freedesktop.org
Sender: "dri-devel"
To: dri-devel@lists.freedesktop.org
List-Id: dri-devel@lists.freedesktop.org
--===============1755633103==
Content-Type: multipart/alternative; boundary="14619786751.B5Bc5bD3e.11283";
charset="UTF-8"
--14619786751.B5Bc5bD3e.11283
Date: Sat, 30 Apr 2016 01:11:15 +0000
MIME-Version: 1.0
Content-Type: text/plain
https://bugs.freedesktop.org/show_bug.cgi?id=95085
--- Comment #15 from Roland Scheidegger ---
(In reply to Nicolai Hähnle from comment #14)
> The trace uses glVertexAttribPointer instead of glVertexAttribIPointer to
> set up a vertex element that will consumed by an uint GLSL variable. I kind
> of suspect that that should be undefined behaviour, but I haven't found a
> corresponding spec reference.
I can't see how that could work (I don't understand how that could work with
some drivers even). glVertexAttribPointer() means the data is really floats -
if you'd use a non-float type to specify it, it will implicitly get converted
to floats. So ok you could cheat there which would leave the data untouched (I
haven't looked at the trace), and rely on the uint input to just read that data
as-is maybe. Not sure if that could work even if you could trick the
implementation to do this - integers as floats have some bad habits, namely all
your negative numbers tend to change their value (as they are NaNs), and your
positive numbers may have some attraction to zero (as they are denorms...).
In any case, just don't do this - these different attrib pointers exist for a
reason. Also see
http://stackoverflow.com/questions/28014864/why-different-variations-of-glvertexattribpointer-do-exist
--
You are receiving this mail because:
You are the assignee for the bug.
--14619786751.B5Bc5bD3e.11283
Date: Sat, 30 Apr 2016 01:11:15 +0000
MIME-Version: 1.0
Content-Type: text/html
Comment # 15
on bug 95085
from Roland Scheidegger
(In reply to Nicolai Hähnle from comment #14)
> The trace uses glVertexAttribPointer instead of glVertexAttribIPointer to
> set up a vertex element that will consumed by an uint GLSL variable. I kind
> of suspect that that should be undefined behaviour, but I haven't found a
> corresponding spec reference.
I can't see how that could work (I don't understand how that could work with
some drivers even). glVertexAttribPointer() means the data is really floats -
if you'd use a non-float type to specify it, it will implicitly get converted
to floats. So ok you could cheat there which would leave the data untouched (I
haven't looked at the trace), and rely on the uint input to just read that data
as-is maybe. Not sure if that could work even if you could trick the
implementation to do this - integers as floats have some bad habits, namely all
your negative numbers tend to change their value (as they are NaNs), and your
positive numbers may have some attraction to zero (as they are denorms...).
In any case, just don't do this - these different attrib pointers exist for a
reason. Also see
http://stackoverflow.com/questions/28014864/why-different-variations-of-glvertexattribpointer-do-exist
You are receiving this mail because:
- You are the assignee for the bug.
--14619786751.B5Bc5bD3e.11283--
--===============1755633103==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs
IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz
dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg==
--===============1755633103==--