On Sat, 31 May 2008 01:41:53 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:
> > > > ... > > > > /* I TOLD YOU! this here STOPS the gradeint bugs. it's a missing > > * emms() before doing floating point operations! the thread pipe code > > * just brought it out reliably. i swear i had seen this long before i > > * ever added the thread/pipe code. > > * > > * now here is why it happens. NO drawing function... EXCEPT > > * evas_common_polygon_draw() and evas_common_gradient_draw() use > > floating > > * point for drawing (the poly stuff should really lose it actually), but > > * nicely nestled in the poly draw code is a evas_common_cpu_end_opt() > > * before it does any operations that would use floating point. the fact > > * is the gradient code was LUCKY before without the thread pipes to > > almost > > * all the time have another func do a evas_common_cpu_end_opt() before > > it > > * was called. that was no longer the case with the thread renderer and > > * it suffered. that is why on amd systems it seemed to work as i beileve > > * on amd cpu's the amms done by evas_common_cpu_end_opt() is not needed > > * to do floatingpoint ops again. > > * > > * after a lot of futzing about - this was the culprit (well axx and axy > > * were garbage values eventually i found after much debugging and i > > traced > > * their garbageness back to here). > > */ > > evas_common_cpu_end_opt(); > > > > angle = (gr->fill.angle * M_PI) / 180.0; > > axx = (cos(angle) * 65536.0); > > ayy = axx; > > axy = (sin(angle) * 65536.0); > > ayx = -axy; > > > > ... > > > > No man, you're not telling me anything I didn't already know. > In fact, this is exactly what I suggested privately to Gustavo was > likely happening and a possible solution to try (seems he never had > a chance to try it). But it's a hack, and not really a fully thread- > safe solution. it's perfectly threadsafe. it has nothing to do with threads. it has to do with there being no emms called before doing fp ops. > And no, the gradient code wasn't "lucky" that all other funcs that > use mmx were releasing those when they finish - that was the very essence > of the design of the no-threads implementation.. it was *expected* that > all funcs were to do that (thus, stating that it was missing an emms call > "somewhere" was spacious and worthless). i have seen the bug before. long ago before the thread code wen it - but it was rare and hard to reproduce. the thread code brought it out in some situations to be 100% reproducable. > You should've realized that adding threads were going to break that > and either fixed it, or said something to me. Instead you did nothing, > said nothing, and when the bug is introduced due to your oversight, you > start claiming that gradients were buggy and always rendered incorrectly > and there was "nothing new".. etc. nothing to do with threads. it had to do with where in the pipeline the emms() was called. > Sorry Carsten, but that was extremely bad form and unbecoming > behavior on you part. again. i have SEEN THIS BEFORE. BEFORE THREADS WENT IN. IT HAS BEEN THERE EVER SINCE your fp code went in. before that gradients never used floating point. it has nothing to do with threads, concurrency, being thread-safe, locking (mutex or otherwise). it has to do with there being floating point code in a pipeline that is 99% non-floating-point. the only other instance of float stuff is in polygons - and it is guarded correctly. the gradient code is not. note an emms can eat up many cycles - it used to use on the order of 140+ cycles last i checked - but that was likely a pentium1 or penitum2. haven't checked recently - so avoiding n emms is a good idea generally. again. it's a missing emms. i repeat - i have seen this bug before - long ago. before i added thread code. it just didn't turn up very often nor was it reproducable easily. this is why i never looked - i knew it was already there. the evas_common_cpu_end_opt() in the polygon code is there from november 2002! that is how long ago that code has worked. the gradient code did not have that in it. note that the previous code had to do emms (evas_common_cpu_end_opt) much more because it didn't have a continuous pipeline like the thread code did - it has a pipe queue that is built then executed - during execution control is kept to rendering, thus being able to drop the emms's... > > ____________________________________________________________ > Need cash? Apply now for a credit loan with fast approval. > http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3m3qYuWNEnKK17HlnGL00olVgS1YmRycoonvoET3uoUOYCAQ/ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
