From: <uni...@sh...> - 2004-08-23 18:46:50
|
Hi! Erdi Chen wrote: > Thomas Hellstr=F6m wrote: > >> I just noticed that you are using a 2d BITBLT to temporarily stall the >> command regulator for a moment. >> >> I believe the XAA implementation in all current via 2d X server driver= s >> out there assume that they are reasonably alone in using the 2d=20 >> engine and >> that they expext that some registers are not changed by other >> applications. This will probably at least break the accelerated X=20 >> server >> pixmap cache, unless used 2d engine registers are restored after the >> BITBLT. > > There is no way to restore registers since the existing values cannot=20 > be determined when the commands are written. XAA code needs to make=20 > use of the ring buffer or it will have to wait for engine idle when=20 > switching between 2D and 3D. Also, 3D code cannot use the ring buffer=20 > unless DDX calls the initialize ioctl. DDX needs to tell DRM where it=20 > can perform this stall bitblt. > The DDX does that and also takes the heavyweight hardware lock before=20 doing any register operations. XAA then also waits on idle vr_queue,=20 command regulator, 2d and 3d engine before doing anything, so that=20 should be safe. The problem is that XAA expects that some register=20 values do not change between calls. I've attached a code snippet from=20 the dri XvMC lib that takes the HW lock, reads registers, BITBLTS and=20 writes registers back, and releases the HW lock. Without writing the=20 original values back, I mess up the screen completely. The remedy is=20 probably to let the via DDX rewrite these values before every 2d engine=20 operation, unless the DRM can do this as part of a context switch. I'm=20 not sure how DRI originally intended this to be done. >> >> I plan to clean up the unichrome 2D driver with respect to this, but I= 'm >> not sure when this will happen. > > DRI code also uses the 2D engine. How does that work? > I'm not totally sure it does. Could be that some of the important=20 registers accidently gets the same value as XAA expects it to have. I have not checked lately, but as of july 1st, the unichrome_dri.so=20 driver messed up overlapping windows and if two simultaneous glxgears=20 were run things got even worse. >> >> W respect to our previous discussion regarding the Mpeg2 decoder >> I'll try programming it using the 2D commands. It might work. >> Thanks for the info. >> >> Is there any chance of having a command stream completion interrupt >> implementation? > > VIA said the hardware does not support it. It's strange that the=20 > older Savage chips had command completion interrupt but not the newer=20 > Unichrome. > >> >> /Thomas >> >> Code snippet: void viaBlit(ViaXvMCContext *ctx,unsigned bpp,unsigned srcBase, unsigned srcPitch,unsigned dstBase,unsigned dstPitch, unsigned w,unsigned h,int xdir,int ydir, unsigned blitMode, unsigned color) { CARD32 dwGEMode =3D 0, srcY=3D0, srcX, dstY=3D0, dstX; CARD32 cmd, saveGEMode,saveSrcBase,saveDstBase,savePitch, saveCKey,saveColor; if (!w || !h) return; switch (bpp) { case 16: dwGEMode |=3D VIA_GEM_16bpp; break; case 32: dwGEMode |=3D VIA_GEM_32bpp; break; default: dwGEMode |=3D VIA_GEM_8bpp; break; } srcX =3D srcBase & 31; dstX =3D dstBase & 31; switch (bpp) { case 16: dwGEMode |=3D VIA_GEM_16bpp; srcX >>=3D 2; dstX >>=3D 2; break; case 32: dwGEMode |=3D VIA_GEM_32bpp; srcX >>=3D 4; dstX >>=3D 4; break; default: dwGEMode |=3D VIA_GEM_8bpp; break; } HW_LOCK(ctx); // Takes the DRM lock viaWaitIdleLocked(ctx); // Waits for idle virtual queue, command=20 regulator and 2d engine. saveGEMode =3D REGIN(ctx,VIA_REG_GEMODE); saveSrcBase =3D REGIN(ctx,VIA_REG_SRCBASE); saveDstBase =3D REGIN(ctx,VIA_REG_DSTBASE); savePitch =3D REGIN(ctx,VIA_REG_PITCH); saveCKey =3D REGIN(ctx,VIA_REG_KEYCONTROL); saveColor =3D REGIN(ctx,VIA_REG_SRCCOLORKEY); REGOUT(ctx, VIA_REG_GEMODE, dwGEMode); cmd =3D 0; if (xdir < 0) { cmd |=3D VIA_GEC_DECX; srcX +=3D (w - 1); dstX +=3D (w - 1); } if (ydir < 0) { cmd |=3D VIA_GEC_DECY; srcY +=3D (h - 1); dstY +=3D (h - 1); } switch(blitMode) { case VIABLIT_TRANSCOPY: REGOUT(ctx, VIA_REG_SRCCOLORKEY, color); REGOUT(ctx, VIA_REG_KEYCONTROL, 0x4000); cmd |=3D VIA_GEC_BLT | (VIA_BLIT_COPY << 24); break; case VIABLIT_FILL: REGOUT(ctx, VIA_REG_FGCOLOR, color); cmd |=3D VIA_GEC_BLT | VIA_GEC_FIXCOLOR_PAT | (VIA_BLIT_FILL << 2= 4); break; default: REGOUT(ctx, VIA_REG_KEYCONTROL, 0x0); cmd |=3D VIA_GEC_BLT | (VIA_BLIT_COPY << 24); } REGOUT(ctx, VIA_REG_SRCBASE, (srcBase & ~31) >> 3); REGOUT(ctx, VIA_REG_DSTBASE, (dstBase & ~31) >> 3); REGOUT(ctx, VIA_REG_PITCH, VIA_PITCH_ENABLE | (srcPitch >> 3) | (((dstPitch) >> 3) << 16)); REGOUT(ctx, VIA_REG_SRCPOS, ((srcY << 16) | srcX)); REGOUT(ctx, VIA_REG_DSTPOS, ((dstY << 16) | dstX)); REGOUT(ctx, VIA_REG_DIMENSION, (((h - 1) << 16) | (w - 1))); REGOUT(ctx, VIA_REG_GECMD, cmd); viaWaitIdleLocked(ctx); // Restores registers. This must currently be done by any code=20 cooperating with the X server. REGOUT(ctx,VIA_REG_GEMODE,saveGEMode); REGOUT(ctx,VIA_REG_SRCBASE,saveSrcBase); REGOUT(ctx,VIA_REG_DSTBASE,saveDstBase); REGOUT(ctx,VIA_REG_PITCH,savePitch); REGOUT(ctx,VIA_REG_KEYCONTROL,saveCKey); REGOUT(ctx,VIA_REG_SRCCOLORKEY,saveColor); HW_UNLOCK(ctx); } >> >> >> ------------------------------------------------------- >> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media >> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 >> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. >> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 >> --=20 >> _______________________________________________ >> Dri-devel mailing list >> Dri...@li... >> https://lists.sourceforge.net/lists/listinfo/dri-devel > > > > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > --=20 > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-deve > l |