On 6/14/2011 10:02 PM, Marc-André Moreau wrote:
> Ah, so we either add Kernel.framework as a dependency on Mac OS X, or
> we wrap a call to the cpuid instruction
>
> Any preference?
>
I have no preference. Are you going to make the change, or do you want
me (or someone else) to work on it?
> By
I finished adding SSE2 optimizations for the Inverse DWT decoding
routines this evening.
Here are the current performance numbers from my Atom D510 test system:
Without SSE:
|---|
PROFILER |
BTW there is a cpuid.h provided by the system, but it's in Kernel.framework:
/Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/i386/cpuid.h
On Tue, Jun 14, 2011 at 9:54 PM, Marc-André Moreau
wrote:
> Hi Steve,
>
> On Tue, Jun 14, 2011 at 10:47 PM, S. E
Ah, so we either add Kernel.framework as a dependency on Mac OS X, or we
wrap a call to the cpuid instruction
Any preference?
By the way, I'm going to start working on NEON soon, I want to turn this
little PandaBoard into an awesome FreeRDP thin client :) I'm reading ARM
documentation right now
Hi Steve,
On Tue, Jun 14, 2011 at 10:47 PM, S. Erisman wrote:
> Marc,
>
>
> On 6/14/2011 7:01 PM, Marc-André Moreau wrote:
>
>> Hi Steve,
>>
>> I noticed the addition of cpuid.h, which is not found on Mac OS X. Is
>> there a more portable alternative for detecting SSE support level? Can't the
>>
Marc,
On 6/14/2011 7:01 PM, Marc-André Moreau wrote:
> Hi Steve,
>
> I noticed the addition of cpuid.h, which is not found on Mac OS X. Is
> there a more portable alternative for detecting SSE support level?
> Can't the cpuinfo instruction be used for this?
That's weird. I was under the assump
Hi Steve,
I noticed the addition of cpuid.h, which is not found on Mac OS X. Is there
a more portable alternative for detecting SSE support level? Can't the
cpuinfo instruction be used for this?
On Tue, Jun 14, 2011 at 3:15 AM, Martin Fleisz
wrote:
> Awesome Steve - congrats! :)
> > SUCCESS!
>
> Correction:
> instead of libfreerdp-app, I think I should have said a new virtual channel
> plugin named rail instead, written just like any other virtual channel
> plugin. In any case, this virtual channel plugin must have a way of letting
> the UI register callbacks, such that the UI can write
Correction:
instead of libfreerdp-app, I think I should have said a new virtual channel
plugin named rail instead, written just like any other virtual channel
plugin. In any case, this virtual channel plugin must have a way of letting
the UI register callbacks, such that the UI can write the "extr
Hi Jay,
On Tue, Jun 14, 2011 at 2:47 AM, Jay Sorg wrote:
> > For 2.2.1 we both agree (they are new secondary orders)
>
> Yup
>
> > For 2.2.2, it contains various things like reporting window movements,
> the
> > language bar, events like minimize, maximize, resize, etc.
> > I agree that we shoul
Good day, Jay.
On Tue, Jun 14, 2011 at 11:32, Roman Barabanov
wrote:
>
In any case now we have 2 possible variants:
- channel communication in the core. I prefer this way, because it simple
(KISS forever) and already fixed in my private plans.
- channel communication out of core: plugin or oth
Good day, Jay.
On Tue, Jun 14, 2011 at 09:47, Jay Sorg wrote:
> > For 2.2.2, it contains various things like reporting window movements,
> the
> > language bar, events like minimize, maximize, resize, etc.
> > I agree that we shouldn't register a virtual channel directly in
> > libfreerdp-core,
>
>>So how does your implementation work for the DirectFB UI that I'm
>> working with currently?
>>
>>Or for any of the other UI's that are here or may be here in the
>>
> future?
>
>>I think it is good if things can stay as common as possible to be
>> shared by the various UI's
> So how does your implementation work for the DirectFB UI that I'm
> working with currently?
>
> Or for any of the other UI's that are here or may be here in the future?
>
> I think it is good if things can stay as common as possible to be
> shared by the various UI's.
>
> Less code an
Awesome Steve - congrats! :)
> SUCCESS!
>
> I figured out the major problem with my SSE code. Apparently you have
> to pay special attention to how the CPU access memory and provide the
> proper cache hints so it doesn't starve itself and make you wait for
> slow RAM accesses.
>
> This simple com
Hi Jay,
So how does your implementation work for the DirectFB UI that I'm
working with currently?
Or for any of the other UI's that are here or may be here in the future?
I think it is good if things can stay as common as possible to be
shared by the various UI's.
Less code and o
16 matches
Mail list logo
