Michel Dänzer wrote:
On Fre, 2002-10-18 at 15:13, Brian Paul wrote:
Keith Whitwell wrote:
Michel Dänzer wrote:
On Son, 2002-10-13 at 17:54, Michel Dänzer wrote:
I've done some more clueless digging into the problem visible in
http://penguinppc.org/~daenzer/DRI/evas_test.jpeg and
http://penguinppc.org/~daenzer/DRI/celestia.jpeg . My first suspicion
was an off-by-one error in the scissor code, but enlarging the scissor
rectangle doesn't help; making it smaller makes the problem worse
though, so the scissor code seems to be correct. So the quads actually
seem to be rendered one pixel too small in both directions;
Actually not. The problem with the evas demo is that the Radeon can't
seem to cope with infinity for texture coordinates (the demo doesn't
render just one quad per background tile, but four of 'em, three having
infinity for some texture coordinates; those aren't rendered). The first
attached patch fixes that, but is a bit awkward; better ideas anyone?
Fix the application. I'm pretty sure we're allowed to bin vertices
containing bogus float values.
The OpenGL spec basically says that NaN/infinite floating point values
can lead to undefined results, but not program terminatation (a crash).
Keith's right, no self-respecting GL app should expect "correct" behaviour
if it's passing in infinite values.
:)
I'm also wondering if Evas is using identical position coordinates for
abutting quads. If not, that would explain the gaps.
That's not the problem, I hope the following debugging output clarifies:
radeonUpdateScissor: (447,52) - (702,307)
radeon_dma_render_quads_verts
vert 0: -0.428571 1.000000 0.000000 1.000000
tex0 0: 0.000000 0.000000
vert 1: 0.140625 1.000000 0.000000 1.000000
tex0 1: 0.996078 0.000000
vert 2: 0.140625 0.335937 0.000000 1.000000
tex0 2: 0.996078 0.996078
vert 3: -0.428571 0.335937 0.000000 1.000000
tex0 3: 0.000000 0.996078
radeon_dma_render_quads_verts
vert 0: 0.140625 1.000000 0.000000 1.000000
tex0 0: inf 0.000000
vert 1: 0.142857 1.000000 0.000000 1.000000
tex0 1: inf 0.000000
vert 2: 0.142857 0.335937 0.000000 1.000000
tex0 2: inf 0.996078
vert 3: 0.140625 0.335937 0.000000 1.000000
tex0 3: inf 0.996078
radeon_dma_render_quads_verts
vert 0: -0.428571 0.335937 0.000000 1.000000
tex0 0: 0.000000 inf
vert 1: 0.140625 0.335937 0.000000 1.000000
tex0 1: 0.996078 inf
vert 2: 0.140625 0.333333 0.000000 1.000000
tex0 2: 0.996078 inf
vert 3: -0.428571 0.333333 0.000000 1.000000
tex0 3: 0.000000 inf
radeon_dma_render_quads_verts
vert 0: 0.140625 0.335937 0.000000 1.000000
tex0 0: inf inf
vert 1: 0.142857 0.335937 0.000000 1.000000
tex0 1: inf inf
vert 2: 0.142857 0.333333 0.000000 1.000000
tex0 2: inf inf
vert 3: 0.140625 0.333333 0.000000 1.000000
tex0 3: inf inf
This is for one 256x256 background tile. It draws a 255x255 quad, then
2x255, then 255x2, then 2x2. All but the first one have infinity for
some texture coordinates, which causes them not to be drawn on a Radeon.
Having some vague memory of the Evas code, I wouldn't be a bit surprised if
this was wrong.
Hehe, it is beyond me why it doesn't simply draw one quad per tile, and
why it uses infinity for texture coordinates...
It might have been a work-around for the limited texture sizes from years
ago. 2k x 2k textures are common now, but weren't a few years ago.
As for the text in celestia, that's fixed by the second patch, which
I'll commit soon unless someone sees a problem with it.
It has the colormaterial change which I said earlier I believe is
incorrect.
That's a late night accident, the first hunk wasn't supposed to be there
either (and there was even another bug in that patch, oh well...). Sorry
about the confusion.
Additionally when changing things like subpixel offsets, please run both
glean and conform to verify that you haven't broken these tests (there
are bugs with both, but fiddling with subpixel can break them totally).
Definitely run Glean.
I will, any particular tests? Where can I get conform?
All the Glean tests are worthwhile (except polygon offset, IMHO). The blending
test is sometimes problematic because some hardware isn't as accurate as it
could/should be.
Conform is not publicly available.
-Brian
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
