Hello, I have now ported the driver to exa_mixed (also because the exa_classic bugfix is not being backported to 1.7 and this way we bypass the issue).
Driver seems to work fine, just like it did under exa_classic. But the same issue remains, mplayer and others still use the fullscreen pixmap as a Xv pixmap and that one is 'pinned'. Once it is pinned I cannot access the base address and thus can't blit the XV image onto the pixmap... I wonder if i need to do exaPrepareAccess() too to make exaMoveInPixmap() actually do something... Can someone also explain what the 'pinned' system is all about on the pixmaps score? -Yves On Thu, Jun 10, 2010 at 09:16:44PM +0200, Maarten Maathuis wrote: > On Thu, Jun 10, 2010 at 8:56 PM, Corbin Simpson > <mostawesomed...@gmail.com> wrote: > > 2010/6/10 Yves De Muyter <y...@alfavisio.be>: > >> Is there any documentation available about the differences between > >> exa_mixed and exa_driver ? Is exa_driver like complete handover of > >> pixmap migration to the driver ? > > > > The three flavors: > > ~ Classic. EXA handles offscreen pixmaps itself. Simple, except when it > > breaks. > > ~ Driver. EXA lets the driver control pixmap allocation and placement. > > Great if you have a memory manager. > > ~ Mixed. Like driver, but certain things have been tweaked to optimize > > certain kinds of acceleration in a way that was never really explained > > to me. > > mixed has parts from classic that avoid touching driver pixmaps > directly for fallbacks (vram is slow to access from the cpu). Xorg's > unique access patterns are not well suited to modern gpu's IMO. That's > why mixed was made. Mixed would be useless if our world was 100% gpu > accelerated, but unfortunately it's not. > > For mixed you can also fail prepare access on the frontbuffer, which > allows you to make a driver that doesn't allow mapping of vram, > provided you have a UTS and DFS hook that always works. > > For igp'ish hardware without dedicated memory and a decent memory > manager, exa driver is preferred because it's the simplest driver mode > and avoids overhead that is unneeded for such hardware. > > > > > To go from driver to mixed is pretty simple; here's an example commit: > > http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=577ff3ce922e457cc32f80d4365cb1da81552e72 > > > > ~ C. > > > > -- > > When the facts change, I change my mind. What do you do, sir? ~ Keynes > > > > Corbin Simpson > > <mostawesomed...@gmail.com> > > _______________________________________________ > > xorg@lists.freedesktop.org: X.Org support > > Archives: http://lists.freedesktop.org/archives/xorg > > Info: http://lists.freedesktop.org/mailman/listinfo/xorg > > Your subscription address: madman2...@gmail.com > > > > > > -- > Life spent, a precious moment, in the wink of an eye we live and we die. > _______________________________________________ > xorg@lists.freedesktop.org: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: http://lists.freedesktop.org/mailman/listinfo/xorg > Your subscription address: y...@connected.be _______________________________________________ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com