| What | Removed | Added |
|---|---|---|
| Assignee | idr@freedesktop.org | dri-devel@lists.freedesktop.org |
| Component | glsl-compiler | Drivers/Gallium/radeonsi |
| CC | maraeo@gmail.com |
| What | Removed | Added |
|---|---|---|
| Resolution | --- | NOTOURBUG |
| Status | NEW | RESOLVED |
Frankly, I don't see how your sample is supposed to render text. The fragment shader only accesses the font texture when nModeOut != 0u, and the value is just passed through from the vertex buffer. According to qapitrace, nModeIn is equal to 0 for all vertices in the final glDrawArrays call... at least based on the apitrace, I'm pretty sure that this is not a driver bug.
| What | Removed | Added |
|---|---|---|
| Resolution | NOTOURBUG | --- |
| Status | RESOLVED | REOPENED |
I spoke too soon. There seem to be several bugs here (one pointed out by Bas Nieuwenhuizen), I'm going to investigate this again in more detail.
I think I understand now where the bug is coming from, and I'm not sure if it's a driver or an application bug :) 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. In any case, it looks like this causes different parts of the driver and the various auxiliary tools to disagree about whether the element should be treated as an int or as a float, and some conversion happens somewhere that makes it all go wrong...
(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
| What | Removed | Added |
|---|---|---|
| Status | REOPENED | RESOLVED |
| Resolution | --- | NOTOURBUG |
The shader only tests for non-zeroness, so it's possible that the difference between radeonsi and the other drivers is that a denorm flush happens somewhere with radeonsi and not the other drivers. Anyway, I'm feeling lucky and closing this as NOTOURBUG for the second time today :)
FYI, the DX10_CLAMP shader bit flushes NaNs to 0. All other floating-point shader opcodes flush denorms to 0. 32-bit denorms can be enabled with a significant performance cost by setting conf->float_mode (see how it's done for FP64).
Sorry for bothering You with our bugs. Next time I'll review the code more precisely, before reporting anything. Thanks everyone for your help.