I wrote:
>> ..............
>> ..............
>>
>> the fact that now there was basically nothing between draw calls to guard
>> against fp op safety - as fp ops were not being used mostly, means that it
>> was
>> much more likely u ended up with the cpu in a non emms state before doing fp
>> ops. even so i found it hard to reproduce in a simple test case - i needed
>> the
>> whole gradient dialog in e to bring it out. (i found that edje_test - the old
>> one did it too eventually). my simple "display a white rectangle and a
>> gradient
>> on top only) test app didnt show the bug. the draw pipeline was too simple
>> and
>> had no mmx/sse state change before drawing the gradient - that is why.
>>
>> as such in the old code in some circumstances the cpu was lest in a bad fp
>> state before entering the gradient draw code - but only very rarely.
>>
>> so i repeat - the code as such is threadsafe. mmx/sse state is separate to
>> threads entirely. the only bit of code outside the gradient code that did fp
>> ops was suitably guarded before doing fps ops. it's much cheaper to guard
>> before the much rarer use of fps ops than guard on every exit from possible
>> mmx/sse ops.
>>
>>
>>
> Let me read thru this is more detail.. But basically Carsten,
> there's a problem with the pipes implementation, or they are somehow
> showing a prior problem of - adequately relasing mmx. One can't
> have this willy-nilly, either one can count on things to do what
> they're supposed to do or fix it. You need to pass floats around,
> you need to know if you can mix this func with fp ops or not, etc.
>
>
I still haven't had a chance to go into this in detail, nor
to go over some of the pipes (and other) code as I'd like.. and
unfortunately I have to run away for a few days so I may not have
a chance to do so for a bit... But, it's just untenable to have
things in this state of affairs man - it's an undesirable source of
potential bugs, inexplicable behavior, indeterminism ... One needs
to be sure what the evas internal functions do or don't do, what
one can count on or not, what behavior to expect, etc.
One can imagine two extreme scenarios of how to deal with
this:
One can fix things by making sure that all mmx use in the
rendering pipeline is 'cleaned-up' correctly - you can still have
known routines which themselves don't clean-up, but they just have
to be used only within ones which do.. and one has to make sure
that always holds, regardless of the possible execution path.
Or, one can modify the rendering pipeline so that one never
uses any fp ops -- they would all be done in render-pre say. This
might be a bit radical and difficult to realize. One must also take
care to consider future extensions -- even now one can have image
'pixel' functions called, and we can't control what's being done
there, even if it's outside the canvas-render func... What about
if one is eventually allowed to provide a rendering function,
ie. one called within the canvas render func? What should they
expect.. and what should evas expect from them?
Whatever the case may be, it's clear that one needs to be
more careful about what's going on, and of what could go on, and
that evas internals need to be more deterministic about fp/mmx,
one way or another.
It's also clear that you need to be bit more careful about
the things you say, and your 'community' behavior in some ways.
____________________________________________________________
Click for online loan, fast & no lender fee, approval today
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3m3WL0hojlmOIaEdHXlXX5W7zi4gfmNJGQt15tepz7LO2utK/
-------------------------------------------------------------------------
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
