On Sat, May 31, 2008 at 4:28 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > Carsten wrote: > >>>> ... >>>> >>>> /* 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. >> >> > > I don't think so. And emms isn't needed there without threads, > not when all funcs clean up after themselves. Disable pipes and you > don't need that. > > >>> 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 saw it in a *very* early version which called emms funcs > *before* the spans were rendered. I saw it then too and shortly > thereafter changed to the current version, which takes care of it - > so long as we're in a non-threaded situation and all funcs (all > unknown ones) which use mmx take care to clean-up, as was the design > expectation. > > If you had told me that after adding the pipes you suddenly > saw gradients completely broken, I could've helped you fix things > then very quickly (it took Gustavo and I very little time, in all, > to pinpoint the likely cause and possible solution). Instead, you > said nothing - something which I was completely unaware of.. and > when people pointed out the bug recently, you made it out like > things had always been broken and that you just never cared enough > to fix it. > > >>> 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... >> > See above - disable pipes and there was no problem, so long as...
Ok, stop you guys! I cannot say for sure since I never played with mmx that much, but I fear raster is right about that. as for thread safety, registers do not need special care for threads, no locks or other requirements, so yes, it should not have any special care. and last but not least, actually the most important bit: gradient is fixed now! Thank you both, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------- 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
