Hello Michel, I've just sent out a v2 of this series, which also fixes a resource leak in the EDID patch.
Am Mittwoch, den 18.07.2012, 11:59 +0200 schrieb Michel Dänzer: > On Mit, 2012-07-18 at 01:26 +0200, Lucas Stach wrote: > > Gives the x-server a more accurate description of the exa hardware > > capabilities. > > [...] > > > @@ -1012,8 +1017,11 @@ xorg_exa_init(ScrnInfoPtr pScrn, Bool accel) > > #ifdef EXA_MIXED_PIXMAPS > > pExa->flags |= EXA_MIXED_PIXMAPS; > > #endif > > - pExa->maxX = 8191; /* FIXME */ > > - pExa->maxY = 8191; /* FIXME */ > > + if (!exa->scrn->get_param(exa->scrn, PIPE_CAP_NPOT_TEXTURES)) > > + pExa->flags |= EXA_OFFSCREEN_ALIGN_POT; > > I don't think EXA_OFFSCREEN_ALIGN_POT really makes sense for st/xorg. It > only affects the pitch, the pixmap dimensions can still be NPOT. I'm not > sure it makes sense trying to make st/xorg work with Gallium drivers > that don't support PIPE_CAP_NPOT_TEXTURES. > Ok, I've dropped this hunk. > Ideally, st/xorg should provide an EXA CreatePixmap2 hook instead of the > current CreatePixmap and ModifyPixmapHeader hooks. > > > > + pExa->maxX = pExa->maxY = > > + 1 << (exa->scrn->get_param(exa->scrn, PIPE_CAP_MAX_TEXTURE_2D_LEVELS) - > > 1); > > This is okay for now, though in the long run we'll probably need > separate caps for hardware such as R300 with different rendering / > sampling size limits. > Yep, will revisit later. > > Your other patches look good, do you have access to push them? No, I don't have commit access. Could you please push them for me? Thanks, Lucas _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev