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... > >> 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? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ------------------------------------------------------- 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
