Gustavo wrote:
>>>> The issue isn't one of safety in the sense of circular
>>>> referencing, it's mmx/fp 'safety', ie. that we know for certain
>>>> that the execution paths aren't being interrupted in such a way
>>>> that although you think you've released mmx registers, and thus
>>>> the next guy is free to use fp ops.. that maybe isn't so.
>>>>
>>> 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.
>>
>>>> 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 obsrved
>> (among other things).
>> If that's so, then why is this ocurring.. what is the exact code
>> path that's being executed that causes such a radical change? This needs
>> to be understood far better than what I've seen in any remarks made by
>> anyone so far.
>>
>
> if I force it to not use pipes, it is ok, but if I just have one
> thread running (by changing code), I still have problems... so it's
> not about multiple threads damaging each other...
>
>
Ummm... Then the pipes implementation needs some inspection,
because something's just not right here.
That emms that raster added should not be needed - pipes or
no pipes. Its presence there justs masks a serious problem, namely
that something that should be releasing mmx registers either isn't
doing so, or the code execution path is not allowing that to be done
correctly when needed.. and this 'seems' to occur only when pipes
are enabled.
It's a problem that needs to be understood and fixed correctly.
>>> Also, as I reported to you in private, the "src" was being calculated
>>> fine, remember that I said that if I just copy the src to dst I was
>>> getting the "correct" gradient, but of course it was not being placed
>>> in the correct angle.
>>>
>> Right, because the fp calculations that gave the matrix were
>> then junk, so the computed geometry was garbage. But the question is:
>> Was this happening *only* when pipes are enabled, or does it happen
>> with pipes diabled as well?
>>
>> I should add that: we *hope* the particular kind of bit of
>> of 'put emms before one begins to use some sequence of fp ops'
>> does indeed solve things in general.
>>
>
> :-)
>
____________________________________________________________
Hotel pics, info and virtual tours. Click here to book a hotel online.
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nLmKzcX8LsMWehVLb7d1P2U2OuAHHGk1KyoF3MSkRKEaCVq/
-------------------------------------------------------------------------
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
