Prev: ===Christian Louboutin - www.vipchristianlouboutin.com
Next: Alphabet_Soup:_a_Collection_of_Microarchitectures
From: Wolfgang.Draxinger on 5 Aug 2010 08:21
Am Thu, 5 Aug 2010 04:11:37 -0700 (PDT)
schrieb Skybuck <skybuck2000(a)hotmail.com>:

> This assumes single copy... if any where in the system additional
> copies have to be made this ofcourse breaks apart.

Actually, I totally messed up my calculations, adding a factor 8,
because I somehow was thinking in bits somewhere not bytes (I should
really have waited for my coffee infusion to take effect).

Actually you have to process only

1920*1200 * 3Bytes * 60/s = 0.41472 GByte/s

THAT's a piece of cake for modern systems.

> And it's highly likely that somewhere in a driver somewhere a copy is
> being made...

Computers are copying machines. About each and every operation you do
involves making at least some copy somwhere. Your typical processor has
about 10 times more instructions to copy data around, than for
processing it.

> Perhaps because of a memory swap between application space/driver and
> kernel space/driver.

That's not, how operating systems and drivers work.


Wolfgang
--
CIP-Rechnerbetriebsgruppe
Fakultät für Physik - LMU München
Schellingstrasse 4, 80799 München

From: fungus on 5 Aug 2010 09:18
On Aug 5, 1:31 am, "Skybuck Flying" <IntoTheFut...(a)hotmail.com> wrote:
> I am thinking 1920x1200x24 bit colors at 60 frames per second.
>
> There is simply no way that any cpu  can achieve that with simply x86....
> very maybe sse etc... but I wouldn't hold my breath ! ;)
>

Huh?

It's simple math... CPUs run at about 3GHz, 1920x1200
is about 2 megapixels.


> Add a few branches in the loop and it's game over 100% for sure ;)
>

Other people can manage to decode HDTV faster than
you can fill RAM? Maybe you need to rethink your
career choice.


From: T. Schroeder on 5 Aug 2010 09:39
Am 05.08.2010 15:18, schrieb fungus:
> On Aug 5, 1:31 am, "Skybuck Flying"<IntoTheFut...(a)hotmail.com> wrote:
>> I am thinking 1920x1200x24 bit colors at 60 frames per second.
>>
>> There is simply no way that any cpu can achieve that with simply x86...
>> very maybe sse etc... but I wouldn't hold my breath ! ;)
>>
>
> Huh?
>
> It's simple math... CPUs run at about 3GHz, 1920x1200
> is about 2 megapixels.
>
>
>> Add a few branches in the loop and it's game over 100% for sure ;)
>>
>
> Other people can manage to decode HDTV faster than
> you can fill RAM? Maybe you need to rethink your
> career choice.
>
>

maybe he should rethink anything... mostly before he post something...

From: Skybuck Flying on 5 Aug 2010 10:20
"
Actually you have to process only

1920*1200 * 3Bytes * 60/s = 0.41472 GByte/s

THAT's a piece of cake for modern systems.
"

I don't agree with that last sentence.

Suppose RLE compression is used, tried it myself.

That means a branch for each color.

That's means: 1920x1200x3x60 = 414.720.000

414 million branches per second !

A branch takes a least 15 cycles.

That means: 414 * 15 = 6210 million cycles needed.

The core on my cpu has 2.0 ghz... so it comes 4210 million cycles short !

There is no way that it can do RLE decompression at that resolution at that
speed ?!

Bye,
Skybuck.


From: Skybuck Flying on 5 Aug 2010 10:25
Actually it's coming back to me...

Extracting bits from a bitstream is a major bottle neck when it comes to
video decompression.

Something like 50 instructions needed for just 8 bits or so... more bits
could require even more instructions.

Especially if it's supposed to be a safe decoder and not something that can
be abused...

^ Branch needed for checks and such.

Bye,
Skybuck.



First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: ===Christian Louboutin - www.vipchristianlouboutin.com
Next: Alphabet_Soup:_a_Collection_of_Microarchitectures