On Wed, 11 Dec 2013 13:37:58 -0500 Christopher Barry <[email protected]> said:
> <mega-snip>... > > Wow all. I'm the OP, and seriously did not mean to cause such a stir or > abrade old wounds with rock salt or anything. > > I guess the bottom line is really "we all get to use Enlightenment for > FREE!". And we love it. It's Raster's baby, and he has the right to do > anything he damn well pleases with it. Period. If we don't like it, > we're free to fork it and provide fglrx functionality. Yeah, I'm using > fglrx (and it's a desktop card) so it's my issue. I too have many > issues with ATI beyond Enlightenment, so the suggestion from experience > was pretty well taken by me. thanks :) and it was a real suggestion. i am glad you took it as such. i did end that suggestion with a smiley eve. *IF* you had replied with a "it's not possible to change (easily)" i might have replied with "are you using fglrx or oss drivers? if fglrx.. it's definitely worse in my experience, try radeon". as i did 2 weeks back to someone else... > I'll admit, at first I was kinda mad, because compiz just 'worked', and > worked well. But after reading 'compiz' was hard coded into their actually didn't you ever notice compiz - when it resized windows, would just draw a box? :) on fglrx, resizing of a window was like continental drift. any resize of a window pixmap was insanely slow. compiz dropped an entire feature to avoid this kind of situation. on my nvidia drivers (and intel too these days) resizing is pretty smooth. this was just another of the problems. (and my bet is that it's because someoen through they should do readback from video memory via the cpu to copy old pixmap content onto a new one... and readback over agp/pcie etc. is like walking from paris to london instead of taking the plane). :) > driver, I had to agree that their code is pretty lame. I tend to defer > to and respect the knowledge and experience of others. (There isn't > enough time to make all the mistakes yourself...) i understand drivers released 6mo, 1y or so AFTER i had this problem no longer did the "compiz process name" check, but by then i had ditched my ati laptop as i was seriously annoyed that my money was wasted AND i had lost 2 weeks of my time beating my head against the "call it compiz or do not function". i am not kidding. i spent two weeks with a test program trying to get texture-from-pixmap to work to avoid pixel copies to texture and thus full acceleration. the REASON that e still supports the ability to run with gl and NOT use texture-from-pixmap (resort to doing its own copies via xshmgetimage and then upload back to texture) is because of this driver experience and getting it to work. i am not joking, when at the end of this 2 weeks, i was almost giving up and i went "please don't tell me they do what i have heard many drivers do on windows - they check their exe name and change behavior based on it...". it was a pure wild guess that this might be the case after exhausting everything else i could think of. so my not-working test binary/app... i just renamed to "compiz" and ran it... ./compiz... and PRESTO. it suddenly worked. no code changes needed. stop calling it compiz and it stopped working. the reason i come down so hard is not just my wasted money on a laptop i couldn't run a compositor i was writing on at all because i that an ati chip (and the "official drivers refused to allow me to do that ... unless i called it compiz, which was not a viable option - yeah. let's rename enlightenment to compiz to ensure it works everywhere). not just that it basically soaked up the cost of that laptop (a pricey $3000) AND 2 weeks of my time - i mean 2 solid full workday weeks. suffice to say that in terms of cost to me personally (at the time i was doing contract work so an hour wasted is an hour of actual paid work DIRECTLY), was far more than the laptop cost, but until the end i didn't know that it was the driver at fault... that's just the side issue. the fact that official supported drivers straight from the linux support team at ati decided that banning compositors other than the one(s) in a whitelist (i only ever checked for compiz as a name change - i didn't go through a list of all possible names, so there may have been others), was to me a form of censorship - "thou shalt not write another compositor (on our hardware) unless we approve!" and that kind of decision making within the walls of the group of people who at the chip vendor support that gpu... tells me that i wanted to have nothing to do with it. if it printfed "you a not compiz. you may encounter bugs as we only tested with compiz" i'd be understanding... as long as it continued to work, just with a warning. i'm passing on that experience and advice whenever someone has problems with the same chipset. :) if it works fine for them - great. no need to do anything. carry on. if it doesn't work... MAYBE try an alternative. i hope this is also a cautionary tale in general. just because a company or some user/person tells you "it works great! use it". take it with a massive grain of salt. test it YOURSELF. don't take it on faith. it may cost you lots of money (in time or in actual cold hard cash in replacing hardware). also a cautionary tale about drivers - closed ones, and what they sometimes do behind their closed up binary walls, and how this can affect people. there are enough other drivers, systems etc. other than ati (at the time) that pull nasty stunts or tricks, and these can have severe consequences. in the above case it was literally impossible to write a compositor on that hardware. in other cases you may find that code that works fine everywhere else is now buggy. it may be the code and a valid situation it never had to deal with before - fix the code, but it may be broken drivers. the sgx drivers for the n900 had a few such nasties. they didn't conform to egl/gles2 specs. if you init an egl context and if you ask for at LEAST 1 bit of red, green abd blue, it fails to init. you must ask for at LEAST 5/6/5 bits. for example. with gldrawarrays, gl specifies that the array size is unlimited in size (or well as many elements as an int can store) and that if the hardware can't handle that large a buffer, it is the drivers job to divide it up into batches. evas gained optimization's to ensure ti handled as large a chunk to the gpu at a time (more vertexes in the array) as possible for best performance, but on these sgx drivers, tests that hit 60,000 vertexes or so were failing. the driver literally didn't do what the spec says it must. the hw obviously had a limit - fair enough. but it didn't handle the "what if we go over that limit" case. of course both of these are much more in your "it's a regular bug" class of issues, and i even filed bugzilla tickets for them. these are cautionary tales i like to expand on every now and again, so that maybe it will help people understand what is going on under the hood, and what kind of problems can arise. of course efl and e has bugs. like everything else. but e's stability can be directly affected by driver stability (and vice-versa). sometimes i wonder "why are people reporting all these crashes and issues... and i never see them? why?". sometimes i wonder if it's an external source - eg a buggy driver corruption heap (or stack)? i don't know. i don't see it. but i also avoid some sets of drivers entirely by a long-time historical choice... and maybe i should pass on that "learned lesson" ? > Anyway, I'll be getting an nvidia card pretty soon most likely. Anyone > know of a good one that can drive three DVI 1920x1200 monitors on > Linux? that - i don't know. though i understand there should be at least a few around - the question is mostly just finding them. maybe not all dvi connectors - maybe 1 dvi and 2 hdmi... but my nvidia at home drives 1920x1200 + 2560x1440 across an hdmi and dvi out. nvidia drivers are not totally trouble-free either. don't get me wrong, but they've never told me what i can or cannot develop on top of their drivers with a whitelist. :) > > -- > Regards, > Christopher Barry > > Random geeky fortune: > BOFH excuse #224: > > Jan 9 16:41:27 huber su: 'su root' succeeded for .... on /dev/pts/1 > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > enlightenment-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
