MGA EXA: problems when writing to A8 textures/pictures

[Tilman Sauerbeck]

Tilman Sauerbeck [2006-09-14 23:11]:
> Ville Syrjälä [2006-09-14 21:11]:
> > On Thu, Sep 14, 2006 at 07:35:55PM +0200, Tilman Sauerbeck wrote:
> > > Ville Syrjälä [2006-09-14 20:06]:
> > > > On Thu, Sep 14, 2006 at 06:31:00PM +0200, Tilman Sauerbeck wrote:
> > > > > Hi,
> > > > > I'm almost finished with the EXA implementation in the MGA driver, but
> > > > > I've got one major problem left.
> > > > > 
> > > > > Rendering to A8 textures is broken in weird ways. It's easily
> > > > > reproducable with rendercheck doing Src blends (you'll need to get
> > > > > rendercheck from git to see the errors though).
> > > > 
> > > > I had a quick look at the code.
> > > > 
> > > > Did you enable bypass332 and nodither bits in MACCESS? I didn't see it.
> > > 
> > > I think I didn't try the combination of these two flags recently.
> > > Using both for A8->A8 writes fixes these rendering issues :)
> > > 
> > > It also adds more artefacts to A8 Add blends though, but these can
> > > probably be fixed by adjusting DUALSTAGE0...
> 
> Okay, here's on the "a8 Add a8" blends (ie, sblendf is SRC_ONE, dblendf
> is DST_ONE):

For these blends, currently every fourth pixel gets set to 0xff, no
matter what the source or destination texture is set to.
The other pixels get the expected alpha value.
It kinda looks like destination texture isn't a8, but rgba or something.

So the a8 destination _reads_ seems to be the problem, since Src
operations on a8 destinations work correctly.

Could it be that I _have_ to disable bypass332 (or nodither?) for
operations where a8 destination reads are involved? I hope not, since
the loss of quality is very noticable :(

Any idea on this?

Regards,
Tilman

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20060930/ab885806/attachment.pgp>