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