Re: [Mesa-dev] SandyBridge not handling GL_TRIANGLE_STRIP_ADJACENCY with repeating vertex indices correctly
On Tue, 2014-08-26 at 15:44 -0700, Kenneth Graunke wrote: On Friday, August 22, 2014 12:59:57 PM Samuel Iglesias Gonsálvez wrote: On Thu, 2014-08-14 at 14:28 +0200, Iago Toral Quiroga wrote: [...] At this point I'd like to hear suggestions for things we could try next to confirm whether this is a hardware problem or a driver problem, or, if we agree that this is enough evidence that this must be a hardware problem, how we can limit its impact, starting, probably, by rewriting the piglit test so that we don't alter its purpose but avoid the hang on gen6. We should also discuss if there is a way to work around this problem so that at least developers running into it (as unlikely as that may be) don't hang their systems. I am going to be on holidays starting tomorrow and will have difficult and limited Internet access for the most part, but Samuel (in the CC) will be available next week to try any suggestions you may have. As Iago said, I'm available for trying any suggestions you may have. I'm wondering if you need more information about the issue or if I can run more tests in order to confirm/discard this is a HW problem and the next steps to follow. Best regards, Sam I just came across an interesting looking errata... From the Sandybridge PRM, Volume 2 Part 1, Section 5.5.1 Partial Object Removal: An object is considered ‘partial’ if the last vertex of the primitive topology is encountered (i.e., PrimEnd is set) before a complete set of vertices for that object have been received. Given that only LINESTRIP and TRISTRIP primitive types are subject to CLIP unit partial object removal, the only supported cases of partial objects are 1-vertex LINESTRIPs and 1 or 2-vertex TRISTRIPs. [errata DevSNB]: Possible hang if final output from GS kernel is 2 vertex triangle. If it is possible for the final output from GS kernel to be a 2 vertex triangle, then have the GS kernel always output an extra single vertex triangle as the final output. Do you think this could be related? It's a SNB specific hang closely tied to triangle strips, which sounds promising, but the symptoms don't sound quite right either... As Iago reported, the issue is specific to glDrawElements(), while glDrawArrays() is not affected. If the errata was the source of the issue, I understand that it should affect both rendering commands, am I wrong? However it is interesting to know this SNB's errata because our GS patches don't take into account that the final output from GS kernel might be 2 vertex a triangle and that could produce another GPU hang. Thanks! Sam signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SandyBridge not handling GL_TRIANGLE_STRIP_ADJACENCY with repeating vertex indices correctly
On Friday, August 22, 2014 12:59:57 PM Samuel Iglesias Gonsálvez wrote: On Thu, 2014-08-14 at 14:28 +0200, Iago Toral Quiroga wrote: [...] At this point I'd like to hear suggestions for things we could try next to confirm whether this is a hardware problem or a driver problem, or, if we agree that this is enough evidence that this must be a hardware problem, how we can limit its impact, starting, probably, by rewriting the piglit test so that we don't alter its purpose but avoid the hang on gen6. We should also discuss if there is a way to work around this problem so that at least developers running into it (as unlikely as that may be) don't hang their systems. I am going to be on holidays starting tomorrow and will have difficult and limited Internet access for the most part, but Samuel (in the CC) will be available next week to try any suggestions you may have. As Iago said, I'm available for trying any suggestions you may have. I'm wondering if you need more information about the issue or if I can run more tests in order to confirm/discard this is a HW problem and the next steps to follow. Best regards, Sam I just came across an interesting looking errata... From the Sandybridge PRM, Volume 2 Part 1, Section 5.5.1 Partial Object Removal: An object is considered ‘partial’ if the last vertex of the primitive topology is encountered (i.e., PrimEnd is set) before a complete set of vertices for that object have been received. Given that only LINESTRIP and TRISTRIP primitive types are subject to CLIP unit partial object removal, the only supported cases of partial objects are 1-vertex LINESTRIPs and 1 or 2-vertex TRISTRIPs. [errata DevSNB]: Possible hang if final output from GS kernel is 2 vertex triangle. If it is possible for the final output from GS kernel to be a 2 vertex triangle, then have the GS kernel always output an extra single vertex triangle as the final output. Do you think this could be related? It's a SNB specific hang closely tied to triangle strips, which sounds promising, but the symptoms don't sound quite right either... --Ken signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SandyBridge not handling GL_TRIANGLE_STRIP_ADJACENCY with repeating vertex indices correctly
On Thu, 2014-08-14 at 14:28 +0200, Iago Toral Quiroga wrote: [...] At this point I'd like to hear suggestions for things we could try next to confirm whether this is a hardware problem or a driver problem, or, if we agree that this is enough evidence that this must be a hardware problem, how we can limit its impact, starting, probably, by rewriting the piglit test so that we don't alter its purpose but avoid the hang on gen6. We should also discuss if there is a way to work around this problem so that at least developers running into it (as unlikely as that may be) don't hang their systems. I am going to be on holidays starting tomorrow and will have difficult and limited Internet access for the most part, but Samuel (in the CC) will be available next week to try any suggestions you may have. As Iago said, I'm available for trying any suggestions you may have. I'm wondering if you need more information about the issue or if I can run more tests in order to confirm/discard this is a HW problem and the next steps to follow. Best regards, Sam signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SandyBridge not handling GL_TRIANGLE_STRIP_ADJACENCY with repeating vertex indices correctly
On mar, 2014-07-29 at 10:12 +0200, Iago Toral Quiroga wrote:
Hi,
running the piglit tests on my implementation of geometry shaders for
Sandy Bridge produces a GPU hang for the following test:
./glsl-1.50-geometry-primitive-id-restart GL_TRIANGLE_STRIP_ADJACENCY
ffs
That test checks primitive restarts but the hang seems to be unrelated
to that, since it happens also when primitive restart is not enabled.
The problem, which only affects GL_TRIANGLE_STRIP_ADJACENCY and no other
primitive type -with our without adjacency-, is in this loop that the
test uses to setup the indices for the vertices:
elements = glMapBuffer(GL_ELEMENT_ARRAY_BUFFER, GL_READ_WRITE);
num_elements = 0;
for (i = 1; i = LONGEST_INPUT_SEQUENCE; i++) {
for (j = 0; j i; j++) {
/* Every element that isn't the primitive
* restart index can just be element 0, since
* we don't care about the actual vertex data.
*/
elements[num_elements++] = 0;
}
elements[num_elements++] = prim_restart_index;
}
glUnmapBuffer(GL_ELEMENT_ARRAY_BUFFER);
Setting all elements to the same index (0 in this case) is the one thing
that causes the hang for GL_TRIANGLE_STRIP_ADJACENCY. A simple change
like this removes the hang:
- elements[num_elements++] = 0;
+ elements[num_elements++] = j != prim_restart_index ? j : j + 1;
Skimming through the docs I have not seen any references to this being a
known problem. In fact, I don't see any references to
GL_TRIANGLE_STRIP_ADJACENCY being special in any way and it seems that
this is not a problem in IvyBridge, since the test runs correctly there.
Does this sound like a hardware bug specific to SandyBridge's handling
of GL_TRIANGLE_STRIP_ADJACENCY or is there something else I should check
before arriving to that conclusion?
If it is a hardware bug I guess we want a workaround for it , at least
to prevent the hang or something but I am not sure what would be the
best option here, I think the only option for the driver would be to
explore the list of indices provided when this primitive type is used
and when we hit this scenario (I'd have to test how many repeating
indices we need for it to hang), error out and do not execute the
drawing command or something... any other suggestions?
This is what I found so far:
1. the problem is specific to glDrawElements. glDrawArrays works well
even if all the vertices used have the same coordinates. To me this
suggests that the problem should not be in our implementation of GS,
since using glDrawArrays or glDrawElements is handled elsewhere and
should be transparent to the implementation of the GS stage.
2. The problem does not happen in all situations, only when we repeat
values in the indices we use with glDrawElements. In particular, I found
that the pattern that leads to the hang seems to be:
- There are only 8 indices and all of them are the same.
- There are more than 8 indices and there is at least one subset of 9
consecutive indices where at least 8 indices are the same (they do not
need to be consecutive within the group of 9).
3. The problem is specific to GL_TRIANGLE_STRIP_ADJACENCY. It does not
hang for any other primitive. In fact, other primitives work well and
produce the expected results. I have not seen specific requirements for
this primitive type in the docs that could justify something like this.
Even GL_TRIANGLE_STRIP_ADJACENCY seems to work well except when there
are repeating vertices with that specific pattern in glDrawElements.
4. The problem seems to be independent of the code we generate in the GS
stage, although this should not be surprising considering 1).
Particularly, the hang persists even in the case of an empty main()
function in the geometry shader (where we generate trivial code that of
course works for any other primitive type).
Based on this my conclusion is that this is very likely a hardware
issue. That, or some very obscure problem in the implementation of the
index buffer in gen6 that I have not seen and that only affects
GL_TRIANGLE_STRIP_ADJACENCY for some reason.
At this point I'd like to hear suggestions for things we could try next
to confirm whether this is a hardware problem or a driver problem, or,
if we agree that this is enough evidence that this must be a hardware
problem, how we can limit its impact, starting, probably, by rewriting
the piglit test so that we don't alter its purpose but avoid the hang on
gen6. We should also discuss if there is a way to work around this
problem so that at least developers running into it (as unlikely as that
may be) don't hang their systems.
I am going to be on holidays starting tomorrow and will have difficult
and limited Internet access for the most part, but Samuel (in the CC)
will be available next week to try any suggestions you may have.
Iago
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
Re: [Mesa-dev] SandyBridge not handling GL_TRIANGLE_STRIP_ADJACENCY with repeating vertex indices correctly
On mar, 2014-07-29 at 10:16 -0700, Kenneth Graunke wrote:
On Tuesday, July 29, 2014 10:12:23 AM Iago Toral Quiroga wrote:
Hi,
running the piglit tests on my implementation of geometry shaders for
Sandy Bridge produces a GPU hang for the following test:
./glsl-1.50-geometry-primitive-id-restart GL_TRIANGLE_STRIP_ADJACENCY
ffs
That test checks primitive restarts but the hang seems to be unrelated
to that, since it happens also when primitive restart is not enabled.
The problem, which only affects GL_TRIANGLE_STRIP_ADJACENCY and no other
primitive type -with our without adjacency-, is in this loop that the
test uses to setup the indices for the vertices:
elements = glMapBuffer(GL_ELEMENT_ARRAY_BUFFER, GL_READ_WRITE);
num_elements = 0;
for (i = 1; i = LONGEST_INPUT_SEQUENCE; i++) {
for (j = 0; j i; j++) {
/* Every element that isn't the primitive
* restart index can just be element 0, since
* we don't care about the actual vertex data.
*/
elements[num_elements++] = 0;
}
elements[num_elements++] = prim_restart_index;
}
glUnmapBuffer(GL_ELEMENT_ARRAY_BUFFER);
Setting all elements to the same index (0 in this case) is the one thing
that causes the hang for GL_TRIANGLE_STRIP_ADJACENCY. A simple change
like this removes the hang:
- elements[num_elements++] = 0;
+ elements[num_elements++] = j != prim_restart_index ? j : j + 1;
Skimming through the docs I have not seen any references to this being a
known problem. In fact, I don't see any references to
GL_TRIANGLE_STRIP_ADJACENCY being special in any way and it seems that
this is not a problem in IvyBridge, since the test runs correctly there.
Does this sound like a hardware bug specific to SandyBridge's handling
of GL_TRIANGLE_STRIP_ADJACENCY or is there something else I should check
before arriving to that conclusion?
Odd. It could very well be, but I don't see anything in the documentation,
either. Could you post a branch with your preliminary code? I'd be happy to
look into the hang and see if I come up with any more useful information...
Samuel uploaded a branch to github here:
https://github.com/samuelig/mesa/tree/gs-and-tf-support-snb
Thanks for looking into this!
If it is a hardware bug I guess we want a workaround for it , at least
to prevent the hang or something but I am not sure what would be the
best option here, I think the only option for the driver would be to
explore the list of indices provided when this primitive type is used
and when we hit this scenario (I'd have to test how many repeating
indices we need for it to hang), error out and do not execute the
drawing command or something... any other suggestions?
Iago
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] SandyBridge not handling GL_TRIANGLE_STRIP_ADJACENCY with repeating vertex indices correctly
Hi,
running the piglit tests on my implementation of geometry shaders for
Sandy Bridge produces a GPU hang for the following test:
./glsl-1.50-geometry-primitive-id-restart GL_TRIANGLE_STRIP_ADJACENCY
ffs
That test checks primitive restarts but the hang seems to be unrelated
to that, since it happens also when primitive restart is not enabled.
The problem, which only affects GL_TRIANGLE_STRIP_ADJACENCY and no other
primitive type -with our without adjacency-, is in this loop that the
test uses to setup the indices for the vertices:
elements = glMapBuffer(GL_ELEMENT_ARRAY_BUFFER, GL_READ_WRITE);
num_elements = 0;
for (i = 1; i = LONGEST_INPUT_SEQUENCE; i++) {
for (j = 0; j i; j++) {
/* Every element that isn't the primitive
* restart index can just be element 0, since
* we don't care about the actual vertex data.
*/
elements[num_elements++] = 0;
}
elements[num_elements++] = prim_restart_index;
}
glUnmapBuffer(GL_ELEMENT_ARRAY_BUFFER);
Setting all elements to the same index (0 in this case) is the one thing
that causes the hang for GL_TRIANGLE_STRIP_ADJACENCY. A simple change
like this removes the hang:
- elements[num_elements++] = 0;
+ elements[num_elements++] = j != prim_restart_index ? j : j + 1;
Skimming through the docs I have not seen any references to this being a
known problem. In fact, I don't see any references to
GL_TRIANGLE_STRIP_ADJACENCY being special in any way and it seems that
this is not a problem in IvyBridge, since the test runs correctly there.
Does this sound like a hardware bug specific to SandyBridge's handling
of GL_TRIANGLE_STRIP_ADJACENCY or is there something else I should check
before arriving to that conclusion?
If it is a hardware bug I guess we want a workaround for it , at least
to prevent the hang or something but I am not sure what would be the
best option here, I think the only option for the driver would be to
explore the list of indices provided when this primitive type is used
and when we hit this scenario (I'd have to test how many repeating
indices we need for it to hang), error out and do not execute the
drawing command or something... any other suggestions?
Iago
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SandyBridge not handling GL_TRIANGLE_STRIP_ADJACENCY with repeating vertex indices correctly
On Tuesday, July 29, 2014 10:12:23 AM Iago Toral Quiroga wrote:
Hi,
running the piglit tests on my implementation of geometry shaders for
Sandy Bridge produces a GPU hang for the following test:
./glsl-1.50-geometry-primitive-id-restart GL_TRIANGLE_STRIP_ADJACENCY
ffs
That test checks primitive restarts but the hang seems to be unrelated
to that, since it happens also when primitive restart is not enabled.
The problem, which only affects GL_TRIANGLE_STRIP_ADJACENCY and no other
primitive type -with our without adjacency-, is in this loop that the
test uses to setup the indices for the vertices:
elements = glMapBuffer(GL_ELEMENT_ARRAY_BUFFER, GL_READ_WRITE);
num_elements = 0;
for (i = 1; i = LONGEST_INPUT_SEQUENCE; i++) {
for (j = 0; j i; j++) {
/* Every element that isn't the primitive
* restart index can just be element 0, since
* we don't care about the actual vertex data.
*/
elements[num_elements++] = 0;
}
elements[num_elements++] = prim_restart_index;
}
glUnmapBuffer(GL_ELEMENT_ARRAY_BUFFER);
Setting all elements to the same index (0 in this case) is the one thing
that causes the hang for GL_TRIANGLE_STRIP_ADJACENCY. A simple change
like this removes the hang:
- elements[num_elements++] = 0;
+ elements[num_elements++] = j != prim_restart_index ? j : j + 1;
Skimming through the docs I have not seen any references to this being a
known problem. In fact, I don't see any references to
GL_TRIANGLE_STRIP_ADJACENCY being special in any way and it seems that
this is not a problem in IvyBridge, since the test runs correctly there.
Does this sound like a hardware bug specific to SandyBridge's handling
of GL_TRIANGLE_STRIP_ADJACENCY or is there something else I should check
before arriving to that conclusion?
Odd. It could very well be, but I don't see anything in the documentation,
either. Could you post a branch with your preliminary code? I'd be happy to
look into the hang and see if I come up with any more useful information...
If it is a hardware bug I guess we want a workaround for it , at least
to prevent the hang or something but I am not sure what would be the
best option here, I think the only option for the driver would be to
explore the list of indices provided when this primitive type is used
and when we hit this scenario (I'd have to test how many repeating
indices we need for it to hang), error out and do not execute the
drawing command or something... any other suggestions?
Iago
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
