[prev in list] [next in list] [prev in thread] [next in thread]
List: kwin
Subject: Re: Compositing manager
From: Thomas =?iso-8859-1?q?L=FCbking?= <thomas.luebking () web ! de>
Date: 2006-07-22 14:40:55
Message-ID: 200607221640.55382.thomas.luebking () web ! de
[Download RAW message or body]
Am Donnerstag, 1. Januar 1970 01:00 schrieb Zack Rusin:
> I'm not sure what you mean when you say "pixmaps through the CPU" but
> it's either way not correct. Pixmaps are stored in vram when available.
> Thanks to AGP gart they're being swapped out to agp memory when there's
> not enough space for them.
ok, first off: maxima mea culpa ;)
it turned out that i really occasionally blowed
up all my 128MB of VRAM (of course this happens when loading huge images...)
(i guess opengl becomes faster in those situations as it 1. frees the vram for
itself (?and 2nd is better on compressing texures?) (of course there's no
desktop wallpaper etc. in a glwindow but i'm not sure if this is the
problem))
however (thanks for teaching, zack):
- the bad thing is, i'll probably need a
new gpu =)
- the REALLY good thing is that i was wrong on this as i now have a couple of
structural problems less as i now believe(!) X won't leave the VRAM for no
sense. (though i don't see the need to leave vram on clipping - maybe this is
a Qt issue? I'll try with plain X clipping)
back on topic -
given this insight, (X has no design problem on pixmap usage, i'm so happy
that i'm stupid =) i see no good reason to exclude XRender from KWin FX stuff
(as soon as XRender sanely HW accelerated by the driver, GL cannot be faster)
And if you need to store a pixmap and a texture for each drawable (so they
don't cover the same bitarray internally), you'll double the RAM demand
(what's crap, as we just learned ;) or need to convert them on the fly for
each frame (what's not efficient as well)
(i don't think that pixmaps are stored as textures internally, as textures
used to need to be x^2 to be efficient while there's no such restriction on
pixmaps. also the nVidia CSS xform wasn't hw accelerated (at least not
comparable to GL) while the blending was, what wouldn't make sense if pixmaps
allready where textures internally - again: correct me if i'm terribly wrong)
So the key issue seems to be to get
1. accelerated blending
2. accelerated scaling
3. shader usage (to get blurrage etc., just flew over glsl: cool stuff ;)
into XRender to make it usefull (in doubt by setting X upon GL)
(and i mean on the CSS drivers mainly and as well. Yes it's not nice, but to
believe nVidia or ATI would open their full specs is ... at least unrealistic
unless one of them had a monopoly - what no one really would like to see. And
yes, there're more GPU vendors out there, but those two cover most of the
common user desktops (jaja... intel is wide spreaded on centrino notebooks
and they're more helpfull on specs, but they're not really in the same league
in Quake4 fps ;))
Thomas
--
Fear... Fear attracts the fearfull.
The strong. The weak. The innocent. The corrupt.
Fear... Fear is my ally!
_______________________________________________
Kwin mailing list
Kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic