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

[Keith Packard]

Michel Dänzer <michel at daenzer.net> writes:

> On 08.04.2014 17:13, Keith Packard wrote:
>> Michel Dänzer <michel at daenzer.net> writes:
>> 
>>> Yes, that works fine now in Xephyr. The only remaining obvious problem
>>> there is the xfwm4 window decoration corruption regression from the
>>> master branch.
>> 
>> Ok, looks like that's caused by glamor re-using FBOs that were too large
>> for tile pixmaps. Oddly, the texture fetch doesn't work like you'd want
>> in that case.
>> 
>> I've added a patch to keep glamor from ever using over-sized FBOs. We'll
>> probably want to re-enable that optimization at some point in the future
>> as it does tend to save a ton of allocation overhead, but we'll need to
>> be careful to only use it when the object isn't being used as a texture
>> source.
>
> Right, or the texture coordinates need to be calculated according to the
> texture size as opposed to the pixmap size. Though that still wouldn't
> work e.g. for Render repeat modes.

I'm hoping we'll be able to simply remove all of the X-server level
pixmap caching; libdrm already caches stuff below us, and is doing a
much more polite job of it.

> Thanks. The crash turned out to be due to a radeon driver bug which is
> fixed in current xf86-video-ati Git master.

Cool.

> I just bisected another problem to the 'glamor: Add glamor_transfer
> based glamor_get_image and glamor_put_image' commit in your current
> glamor-server branch though: As of that commit, the icons in libreoffice
> are 'washed out' for me. Looks like something goes wrong with the alpha
> channel.

Hrm, I wonder if I missed some settings for the upload path?

> Other than that (and the OpenGL context management issues) though, the
> current glamor-server branch works well for me, and performance is very
> good. Also, apart from the FBO size fix on there, the copy acceleration
> changes seem to fix a memory leak in glamor_copy_n_to_n, the fix for
> which would otherwise need to be ported from the standalone glamor tree.
> So, what's your plan for this branch vs. the 1.16 release?

Personally, I'd rather fix bugs using my new code than take patches for
the old code, but I'll leave that decision up to Eric, the glamor maintainer.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140416/0fc37777/attachment-0001.sig>