On 22/10/2007, Stefan Dösinger stefan@codeweavers.com wrote:
The shader works in the end, but the complaints pollute the logs and make tracking real failures more difficult.
I don't think this change makes things better there.
Am Montag, 22. Oktober 2007 14:57:40 schrieb H. Verbeet:
On 22/10/2007, Stefan Dösinger stefan@codeweavers.com wrote:
The shader works in the end, but the complaints pollute the logs and make tracking real failures more difficult.
I don't think this change makes things better there.
One issue is that those ignorable warnings spam the debug output and make it difficult to spot real warnings. The draw_buffer warning is only one of them, Apple also warns about BindAttribLocation calls for undefined Attributes. At some point the driver seems to cut off further warnings, so real issues get lost.
My other concern is that some GL implementations do not realize that draw_buffers isn't really used, and turns on things we do not need because we request the extension. I doubt this applies to macos, its optimizer is quite sane as far as I can see.
I agree that this patch makes the glsl code a bit more complex, and I am fine with keeping it in my junk branch. But I think having it in the tree makes the life easier for newcomer developers and users by making sure they don't get flooded with false warnings. (Not that we have any mac d3d developers except me, but false warnings won't help with that).
On 22/10/2007, Stefan Dösinger stefan@codeweavers.com wrote:
Am Montag, 22. Oktober 2007 14:57:40 schrieb H. Verbeet:
On 22/10/2007, Stefan Dösinger stefan@codeweavers.com wrote:
The shader works in the end, but the complaints pollute the logs and make tracking real failures more difficult.
I don't think this change makes things better there.
One issue is that those ignorable warnings spam the debug output and make it difficult to spot real warnings. The draw_buffer warning is only one of them, Apple also warns about BindAttribLocation calls for undefined Attributes. At some point the driver seems to cut off further warnings, so real issues get lost.
My other concern is that some GL implementations do not realize that draw_buffers isn't really used, and turns on things we do not need because we request the extension. I doubt this applies to macos, its optimizer is quite sane as far as I can see.
I agree that this patch makes the glsl code a bit more complex, and I am fine with keeping it in my junk branch. But I think having it in the tree makes the life easier for newcomer developers and users by making sure they don't get flooded with false warnings. (Not that we have any mac d3d developers except me, but false warnings won't help with that).
Probably, but the warnings are a driver problem, not a wined3d problem. The really bad part is that if the drivers ever get fixed we end up with workarounds for problems that no longer exist.
Am Montag, 22. Oktober 2007 17:41:33 schrieb H. Verbeet:
Probably, but the warnings are a driver problem, not a wined3d problem. The really bad part is that if the drivers ever get fixed we end up with workarounds for problems that no longer exist.
This is a good point, if we put such a workaround in it is pretty unlikely that we'll retest for it and remove it, unless it makes active problems.
On the other hand, broken drivers tend stay around even if the newest version. This here happens on MacOS 10.4, and since 10.5 is due to ship in a few days, I don't expect any more than security updates for 10.4, but it will remain important for quite some more time because the update is not free.
I looked for some other reports of this issue, and it seems that some fglrx and card combinations are affected by a similar problem. I never saw it myself, but fglrx floods us with spec-violating success messages, so I never spent much attention at the driver output...
-
H. Verbeet -
Stefan Dösinger