[PATCH 00/20] New glamor core rendering code (v2)

[Michel Dänzer]

On Die, 2014-04-01 at 16:01 -0700, Keith Packard wrote:
> Michel Dänzer <michel at daenzer.net> writes:
> 
> > Sounds great, but...
> >
> > Patch 11 breaks Xorg for me with radeonsi. It looks like solid fills are
> > basically not rendered at all anymore, so e.g. only the text is visible
> > in an xterm window. Then later patches make it even worse, resulting in
> > just a black screen instead of the root weave and an xterm window. Also,
> > e.g. x11perf -shmput500 gives ridiculously high results, so apparently
> > nothing is actually rendered.
> 
> Ok, I found a pervasive mistake in the new glamor code -- my _nf
> functions were not falling back to fb/mi when the driver would be unable
> to access the pixmaps -- they weren't calling
> glamor_ddx_fallback_check_pixmap ever.
> 
> I've fixed that, which makes Eric's patched xf86-video-intel 'just work'
> with the new acceleration code.
> 
> I'd love to know if this also fixes radeonsi, but I don't have any
> hardware to try it on.

The radeon driver doesn't use the glamor_*_nf() entrypoints, it leaves
all the rendering and fallback handling to glamor.


> > Xephyr works mostly fine at patch 20, but e.g. gtkperf leaves artifacts
> > (it's fast though :).
> 
> Can you isolate which tests are causing problems? I'm not seeing this; I
> assume that's because of the difference in GL drivers.

E.g. the GtkComboBox test leaves artifacts outside of the gtkperf
window, or also just scrolling the gtkperf widget containing the test
results.

I think at least part of the problem is using glCopyPixels for
overlapping copies. 3D cores just cannot do that; if any versions of the
OpenGL spec do not explicitly say this produces undefined results,
that's probably just an oversight in the spec, as Markus pointed out.


-- 
Earthling Michel Dänzer            |                  http://www.amd.com
Libre software enthusiast          |                Mesa and X developer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 173 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140408/af8ed262/attachment-0001.sig>