https://bugs.freedesktop.org/show_bug.cgi?id=81174
--- Comment #21 from Brian Paul ---
I found/fixed another long line loop issue. Patch "vbo: fix another
GL_LINE_LOOP bug" has been posted for review.
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=81174
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=81174
--- Comment #19 from Brian Paul ---
(In reply to Brian Paul from comment #16)
> Unfortunately, after fixing the VBO code, there's still a bug somewhere in
> the gallium 'draw' code. See comments in the patch series for more
> information.
I've
https://bugs.freedesktop.org/show_bug.cgi?id=81174
Brian Paul changed:
What|Removed |Added
CC||ideasma...@gmail.com
--- Comment #17 from B
https://bugs.freedesktop.org/show_bug.cgi?id=81174
Brian Paul changed:
What|Removed |Added
CC||dongsheng.x...@intel.com
--- Comment #18 fr
https://bugs.freedesktop.org/show_bug.cgi?id=81174
--- Comment #16 from Brian Paul ---
I'm digging into this bug because it pertains to an issue with a particular app
and the VMware gallium driver.
The VBO code for splitting GL_LINE_LOOP is actually correct, I believe, but our
implementations of
https://bugs.freedesktop.org/show_bug.cgi?id=81174
--- Comment #15 from Florian Link ---
In addition to the above bug, I found that the stippling pattern is reset when
the intermediate buffer is commited. Thus, GL_LINE_STRIP and GL_LINE_LOOP
stipple patterns jump at the same places where the GL_L
https://bugs.freedesktop.org/show_bug.cgi?id=81174
--- Comment #14 from Roland Scheidegger ---
In my testing this seems to be *both* a core (vbo) and a draw problem.
With my piglit test the first error (without redrawing) appears with 4097
vertices - despite that the vbo code can handle 5460 (per
https://bugs.freedesktop.org/show_bug.cgi?id=81174
--- Comment #13 from Roland Scheidegger ---
(In reply to comment #12)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > Line loops aren't so critical, since they are rarely used. But what about
> > > triangle strips... every split kil
https://bugs.freedesktop.org/show_bug.cgi?id=81174
--- Comment #12 from Marek Olšák ---
(In reply to comment #9)
> (In reply to comment #8)
> > Line loops aren't so critical, since they are rarely used. But what about
> > triangle strips... every split kills 2 triangles...
>
> That shouldn't hap
https://bugs.freedesktop.org/show_bug.cgi?id=81174
--- Comment #11 from Marek Olšák ---
(In reply to comment #10)
> What I don't understand yet is why the effect is not stable (if my example
> is repainted several times, the wrap appears at different positions over
> time).
The wrap is done when
https://bugs.freedesktop.org/show_bug.cgi?id=81174
--- Comment #10 from Florian Link ---
What I don't understand yet is why the effect is not stable (if my example is
repainted several times, the wrap appears at different positions over time).
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=81174
--- Comment #9 from Roland Scheidegger ---
(In reply to comment #8)
> Line loops aren't so critical, since they are rarely used. But what about
> triangle strips... every split kills 2 triangles...
That shouldn't happen, the code is supposed to
https://bugs.freedesktop.org/show_bug.cgi?id=81174
--- Comment #8 from Marek Olšák ---
Line loops aren't so critical, since they are rarely used. But what about
triangle strips... every split kills 2 triangles...
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=81174
--- Comment #7 from Roland Scheidegger ---
Hmm interesting. I thought more than 512 vertices would fit before it uses a
new buffer (the buffer size is 64kB though I don't know what the vertex size
ends up with). But if the bug is due to that I gu
https://bugs.freedesktop.org/show_bug.cgi?id=81174
--- Comment #6 from Marek Olšák ---
vbo_save_api.c is for display lists. Direct execution is done in vbo_exec_api.c
and vbo_exec_draw.c. Other than that, your understanding is correct.
--
You are receiving this mail because:
You are the assigne
https://bugs.freedesktop.org/show_bug.cgi?id=81174
--- Comment #5 from Florian Link ---
I had a look at the code and it looks like the problem is that
the data is collected in a VBO in file:
vbo_save_api.c
and if the VBO_SAVE_BUFFER_SIZE is exhausted, the buffer is drawn as
a line loop, even if
https://bugs.freedesktop.org/show_bug.cgi?id=81174
--- Comment #4 from Florian Link ---
That sounds like a reasonable explanation, except that the closing lines of the
line loops are not always the same, they change when the same line loop is
rendered again. But maybe there is some kind of ring b
https://bugs.freedesktop.org/show_bug.cgi?id=81174
--- Comment #3 from Marek Olšák ---
No. If you use the immediate-mode style rendering (glBegin/End), the vertices
are written into a buffer. When the buffer is full, all vertices are drawn and
a new buffer is allocated for the following vertex da
https://bugs.freedesktop.org/show_bug.cgi?id=81174
--- Comment #2 from Benjamin Bellec ---
Is that a regression ?
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http:/
https://bugs.freedesktop.org/show_bug.cgi?id=81174
Benjamin Bellec changed:
What|Removed |Added
CC||b.bel...@gmail.com
--
You are receivi
https://bugs.freedesktop.org/show_bug.cgi?id=81174
--- Comment #1 from Florian Link ---
Created attachment 102537
--> https://bugs.freedesktop.org/attachment.cgi?id=102537&action=edit
A Qt example that demonstrates the problem
--
You are receiving this mail because:
You are the assignee for t
https://bugs.freedesktop.org/show_bug.cgi?id=81174
Ilia Mirkin changed:
What|Removed |Added
Attachment #102536|text/plain |image/png
mime type|
23 matches
Mail list logo
