Enlightenment

Carsten wrote:

> On Sat, 31 May 2008 13:17:42 -0400 Jose Gonzalez <jose_ogp@...> babbled:
>
>   
>>    Gustavo wrote:
>>     
>>> I believe it's up to OS to save/restore all the registers when you
>>> change threads. Am I wrong?
>>>       
>>       I have no idea what happens with this, or how using multiple cpu
>> cores affects that.
>>     
>
> that was my point. it is THREAD SAFE. the os restores registers and cpu state
> between context switches between threads/processes. its internal
> process/threads state with the mmx/sse/fp state. the fact that pipes
> restructured what gets called and how the calls get called and in what stages
> they get called that brought it out reliably in certain situations. you will
> find MOST of the drawing calls do NOT gaurd themselves on exit with an emms
> (evas_cpu_end_opt). the only one actually was the line draw. no others do.
> doing an end_opt at every draw call is not cheap - on older cpu's definitely
> not. as most of evas's calls use NO floating point (and the polygon stuff
> really doesn't need to - i should remove that) there is nigh zero need for what
> is a mostly useless call - and so it can go at the end of the pipeline or just
> before any of the rare fp calls. again - nothing to do with threads. all to do
> with streamlined rendering pipelines.
>
>   
>>>>      There is much too great a difference in the behavior of the
>>>> code with vs. without pipes to say for certain that the code-execution
>>>> paths are well understood.
>>>>     
>>>>         
>>> But do you remember my tests where I disabled the other threads, just
>>> launching one and still having this behavior?
>>>
>>>   
>>>       
>>       As I understood you, as soon as you disabled pipes the problems
>> disappeared - presumably mmx is being released adequately, and indeed
>> I know of no cases where a problem has being observed (with recent cvs)
>> without pipes or on single-core systems. And when you enable pipes again,
>> the problem came back immediately. That's what I thought you observed
>> (among other things).
>>     
>
> this was my point. there has been, in the past, a case where this DOES happen.
> i have seen it - but it was very rare and i didn't have any reliably
> reproducable test case. the code used to do things like this
>
> canvas-level-render
>   each-object
>     calculate-all-things-to-draw about object and maybe call pre-render
> callbacks etc. etc. (all of this may be out of evas/engine/software engine
> controls)
>       setup draw
>         actually call draw call
>     calculate-all-things-to-draw about another object ...
>       setup draw
>         actually draw
>     calculate-all-things-to-draw about another object ...
>       setup draw
>         actually draw
>     calculate-all-things-to-draw about another object ...
>       setup draw
>         actually draw
>     ...
>
> that is how it STILL goes without the thread code enabled - the thread code
> literally removes all the pipe code. that is why it goes away. the fact that
> cpu control can exit the rendering pipeline into callbacks or canvas space
> means that there were (almost always) guards on the fp (ie emms calls) and thus
> entering gradient drawing calls almost always worked fine.
>
> when there is a pipeline - even 1 single pipeline - even if i removed every
> pthread call and put a pipeline "inline" it goes like:
>
>
> canvas-level-render
>   each-object
>     calculate-all-things-to-draw about object and maybe call pre-render
> callbacks etc. etc. (all of this may be out of evas/engine/software engine
> controls)
>       setup draw
>     calculate-all-things-to-draw about another object ...
>       setup draw
>     calculate-all-things-to-draw about another object ...
>       setup draw
>     calculate-all-things-to-draw about another object ...
>       setup draw
>     ...
>   flush pipeline
>     draw
>     draw
>     draw
>     draw
>     ...
>
> and of course the flush pipeline may have multiple pipelines start their draw
> cycles all at once in parallel. it splits up the destination render regions into
> N regions and each pipeline - each in its own thread, each thread is forcibly
> thrust onto its own cpu/core (so threads can't migrate between cpu's/cores).
>
> 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.


____________________________________________________________
Click here for great computer networking solutions!
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oHgMv9zmVkgVWv5Rm2tfChPOUl3yNBqGIsCfOQrBYN84j24/

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/

Thank you all for fixing it :)
Now Edjy can work on everyones systems! Yay! :)
Toma