Carsten wrote:
> On Sat, 31 May 2008 13:17:42 -0400 Jose Gonzalez <[EMAIL PROTECTED]> 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/
-------------------------------------------------------------------------
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
