[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]