On Fri, Aug 26, 2011 at 23:10, Ingvaldur Sigurjonsson <[email protected]> wrote: > On 08/26/2011 02:26 AM, Carsten Haitzler (The Rasterman) wrote: >> On Thu, 25 Aug 2011 23:27:09 +0200 Ingvaldur Sigurjonsson >> <[email protected]> said: >> >>> This is a sad read. I've read some similar complaints on the wine >>> buglist were they're complaining about the lack of shader support on fglrx. >>> >>> Dont know AMD's stand on this point, but wouldn't it be in their >>> interest to fix this ? >>> >>> My last two motherboards have had integrated AMD Radeon HD gfx chips (HD >>> 3200, HD 4290) and more will be coming with all this Fusion thingy on >>> it's way. >>> It's just plain [bs]ad that they wont be supported. >> let me clear this up. fglrx drivers DO support GLSL shaders well if the GPU >> does it. what they screw up with is other things. stability for one. where on >> other drivers things are rock stable, on fglrx things occasionally crash. and >> that brings me to when i started working on compositing. this requires i make >> texture-from-pixmap work. i started with a test app. i created pixmaps and >> tried to make textures from them. i spent DAYS trying to make it work. >> nothing >> did. i banged my head on my desk again and again. the ati card based machine >> was all i had to work with. eventually just on a whim i renamed my executable >> to "compiz". SUDDENLY it worked. zero code changes. that royally pissed me >> off. >> it stunned me. sure - in newer fglrx drivers they fixed this, and thats the >> only reason compositing kind-of-works with e+fglrx, BUT.. the fact that ati >> driver developers would have the audacity to go "hey.. we will only make this >> feature work if you are compiz" amazes me. i just have ZERO trust in their >> work. the last time i tried texture-from-pixmap would work but get you segv's >> relatively frequently AND... it will just miss updates (eg a blinking xterm >> xursor will just miss blinks, or text draws get missed by xterm etc.) this is >> with direct rendering which works just dandily on nvidia and intel drivers. >> >> all of this is another burn i had with fglrx+ati. years ago on an R250 i had >> in >> a dell laptop... i used the fglrx drivers because it was the ONLY way to >> support 3d. guess what? instability, bugs, low featureset in gl (lots of >> extensions that should have been supported were not) and i threw in the towel >> on ati then. this is the 2nd time ati and its closed drivers have burned me >> with bugs and poor implementation. it hasnt improved much over the past 8 or >> so >> years. >> >> admittedly there are "open drivers". when i got my more recent ati (the one i >> was doing compositing work on) i tried the radeon drivers (open ones). my gpu >> was "too new" and wasn't properly supported. this was maybe 2 years ago or >> so, >> i had to go fglrx. i havent tried the open ones, but given some reports from >> users with evas+gl a while back, the open drivers simply didn't do GLSL on >> their >> ati cards even though the hw can. the GLSL compiling failed at runtime. so >> their experience - maybe 9 months ago or so was "shaders no workie". this may >> have now been fixed, but frankly, i stopped caring. i have been burnt by the >> ati/amd world and i ditched that laptop with ati in it and have since been >> happy and able to do development with many fewer hassles on nvidia. if the >> fglrx drivers have improved - fine, or if the open radeon drivers now better >> support shaders - then fine, but my experience and thus my advice is... "keep >> clear of ati if you want stuff to work". >> >> i am a developer and i have enough issues and bugs in my code to sort out >> until >> its working and dont have the time to deal with a mountain of bugs inside the >> drivers i depend on. evas's gl engine works a charm on opengl-es2 drivers >> from >> commercial vendors. it works a charm on nvidia's closed drivers on desktop. >> it >> works dandily on nvidia's tegra2 opengl-es2 drivers. it works find on the >> intel >> GMA3150 and 945gm based devices i have here (with 1 problem the gma3150 >> doesnt >> have hardware vertex shaders (does have hw fragment shaders) so it emulated >> vertex shaders in software which means... slow performance if you throw lots >> of geometry at the gpu - rather poor form there intel! :( at least newer >> intel >> gpu's no longer have this problem - one day i will get around to working >> around >> this by having less geometry to throw at the gpu in some evas modes, but i'll >> do that when i improve evas's rendering core next). so the one gpu i have had >> major problems with that made me entirely abandon entire machines over were >> the >> ati drivers. both open and closed. i don't have any good experiences with ati >> to talk about. if i did - i'd day so here. >> > I totally understand your frustration over amd's propritary drivers > (fglrx,...) and cant do nothing more than sending you some virtual > sympathy hugs. > > I've regularly been trying new versions of the fglrx because I'm > optimistic that they fix all known issues in every release. I know > better now after having thought about my previous experience, your > answer and by digging through several bug-reports wrg shaders (see [1] > and [2]). I guess the AMD driver developers are forced to focus on > Windows driver and only get to throw some rest bits to the Linux > counterpart on their free time, atleast I get that impression. > > So I removed the 11.8 fglrx and reinstalled mesa-libGL (Fedora 15), > rebootet, and again chose Engine=OpenGL in settings. Voila ! E17 works > like a charm. > > glxinfo gives me this: > OpenGL vendor string: X.Org > OpenGL renderer string: Gallium 0.4 on AMD RS880 > OpenGL version string: 2.1 Mesa 7.11 > OpenGL shading language version string: 1.20 > > Dont know if the shading lang. version is high enough for Evas, but the > current speed and effects are more than enough for me and my desktop. > > I even downloaded, built and tried the 'piglit'-testsuite, but they > failed both in the sanity tests. The test when run with fglrx looked > much worse than when running on Gallium/Mesa/radeon thingy, it looked > all greek to me so I just opened me a beer. > > Would that be an option for you/E-folks, to use piglit to determine if > it's worth any effort to make E/Evas run on fgrlx. I.e. when the basic > shader tests wont pass in piglit, then you can just continue ignoring fglrx. > > The ultimate goal would be to have a functioning driver for the > underlying hardware which provides hardware acc. to the degree its built > for. At least I would be happy for that but I guess that will have to > stay on my wishlist. > > Regards > - Ingi > > [1] http://bugs.winehq.org/show_bug.cgi?id=7411 > [2] http://www.amdzone.com/phpbb3/viewtopic.php?f=508&t=138540 >
For what it's worth: yes, fglrx sucks, everybody knows that, BUT I don't have much trouble with it and e17. composite works, it is generally stable and all features work like they should. The _only_ thing that is trouble here is the invisible root-window which makes it impossible to use the nice detorious theme because everything becomes semi-transparent. ------------------------------------------------------------------------------ EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev _______________________________________________ enlightenment-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
