Sandy Bridge Video acceleration in x264

[drwho?]

Hi Guys,

I am Francois Piednoel , Senior Performance analyst at Intel Corp Santa Clara ...
I am known for some Instruction designs, skulltrail, and few other gadget, I worked on LDDQU and MPSADBW etc ... and putted some magics into few hardware piece when giving feedback during the design of the CPUs.I am finalizing a prototype of x264 using the acceleration of Sandy Bridge, the next generations of Intel Processors.

In the mean time, I got the Encoding part kind of under control yet ;-) ... We can offer as well direct decoding hardware capability and connect all of this into the processor cache without getting out of the processor socket ... yeap ... it is going to scream :-P

So, I am looking for one or few of the software Architects of x264 to help me to define the API we can agree on to boost the all story, adding a full decode to encode = Transcode to x264. (I already got my idea of it, but since it is your code ... better get your way of doing it)

I already spoke to Lauren , and I am planning to open the code in few weeks. After that, you guys will be able to adjust and tune the way you want it.
The toy will be fully open source, and we will give full autorization to use the code in an unlimited way. (I am still working on clearing all of this, since we are so close to the hardware)

If you are interested, and ready to spend a good amount of time on the phone and coding with me, please contact me on francois*piednoel$intel.com where the * is a . and the $ is an @.
I ll be posting on few forums to get the best feedback, Let's do it, exciting!

Francois Piednoel
Intel Corp

[Dark Shikari]

Hi Guys,

I am Francois Piednoel , Senior Performance analyst at Intel Corp Santa Clara ...
I am known for some Instruction designs, skulltrail, and few other gadget, I worked on LDDQU and MPSADBW etc

So you're known for two instructions that are utterly useless?

... and putted some magics into few hardware piece when giving feedback during the design of the CPUs.I am finalizing a prototype of x264 using the acceleration of Sandy Bridge, the next generations of Intel Processors.

If it's using a hardware block instead of x264, it isn't x264.  Of course, If you've come up with a way to integrate the hardware block with x264 while maintaining bit-exact output, I'd like to know.

In the mean time, I got the Encoding part kind of under control yet ;-) ... We can offer as well direct decoding hardware capability and connect all of this into the processor cache without getting out of the processor socket ... yeap ... it is going to scream :-P

Well, going by the benchmarks (the Anandtech iPod encode), Sandy Bridge's encoder core is still 2-4 times slower than x264 on its own.  Does your patch make it less horribly slow, or does it use it to offload a small portion of the encoding process so as not to slow down the rest of x264?

So, I am looking for one or few of the software Architects of x264

Well, you've come to the right place!

to help me to define the API we can agree on to boost the all story, adding a full decode to encode = Transcode to x264.

x264 is an encoder, not a decoder.  I don't see how decoding is relevant to x264.

(I already got my idea of it, but since it is your code ... better get your way of doing it)

Why didn't you talk to us before you started development, as opposed to months later?  I work for multiple companies who have extremely close contact with Intel, including some with large investments by Intel, and none of us were even told about Sandy Bridge's encoder core.

If you'd like to fix this now, drop by #x264dev on Freenode.  Just keep in mind for the future that such things are best planned before, and not after the fact.

I already spoke to Lauren

If by "spoke with" you mean "said hi to", perhaps.  He apparently didn't get any information from you beyond an introduction.

Of course, none of this has any bearing on the future; we'd of course be happy to try to work to optimize for the Sandy Bridge, but we're going to have to start from nothing here, since that's where we're at.

[aegisofrime]

x264 is an encoder, not a decoder.  I don't see how decoding is relevant to x264.

Well, if I understand correctly, he's talking about using Sandy Bridge to decode source video, possibly using the video decode engine, and passing the decoded video to x264 to be encoded?

[Dark Shikari]

Well, if I understand correctly, he's talking about using Sandy Bridge to decode source video, possibly using the video decode engine, and passing the decoded video to x264 to be encoded?

Yeah, that would surely be useful, but that would go in libavcodec (along with DXVA, VDPAU, VAAPI, etc), not x264.  It's always best to maximize the number of applications that can easily take advantage of such support.

[multicast]

Hi Guys,

I am Francois Piednoel , Senior Performance analyst at Intel Corp Santa Clara ...
I am known for some Instruction designs, skulltrail, and few other gadget, I worked on LDDQU and MPSADBW etc ... and putted some magics into few hardware piece when giving feedback during the design of the CPUs.I am finalizing a prototype of x264 using the acceleration of Sandy Bridge, the next generations of Intel Processors.

In the mean time, I got the Encoding part kind of under control yet ;-) ... We can offer as well direct decoding hardware capability and connect all of this into the processor cache without getting out of the processor socket ... yeap ... it is going to scream :-P

So, I am looking for one or few of the software Architects of x264 to help me to define the API we can agree on to boost the all story, adding a full decode to encode = Transcode to x264. (I already got my idea of it, but since it is your code ... better get your way of doing it)

I already spoke to Lauren , and I am planning to open the code in few weeks. After that, you guys will be able to adjust and tune the way you want it.
The toy will be fully open source, and we will give full autorization to use the code in an unlimited way. (I am still working on clearing all of this, since we are so close to the hardware)

If you are interested, and ready to spend a good amount of time on the phone and coding with me, please contact me on francois*piednoel$intel.com where the * is a . and the $ is an @.
I ll be posting on few forums to get the best feedback, Let's do it, exciting!

Francois Piednoel
Intel Corp

"I am Francois Piednoel , Senior Performance analyst at Intel Corp Santa Clara ...
I am known for some Instruction designs, skulltrail, and few other gadget, I worked on LDDQU and MPSADBW etc ... and putted some magics into few hardware piece when giving feedback during the design of the CPUs.I am finalizing a prototype of x264 using the acceleration of Sandy Bridge, the next generations of Intel Processors."

and theres your problem Right there "and putted some magics into few hardware piece when giving feedback during the design of the CPUs."

Where exactly were YOU and related designers when actually designing this kit and thinking of new microcode and algorithm's to use ?

as far i as i know, you did NOT even Once ask the world class x264 assembly dev's what new hardware assisted microcode they might like to see , Help You create and TEST to make x264 and other type Encoder problem's better and faster , not to mention actual visual Quality based.

 it seems now's not the time to come asking for Software help and insight into fixing the real work data throughput problems that you may find are now surfacing and will do in the future, did you or the person reasonable for that task, even bother to automatically ship any new prototype silicon and boards to the x264/FFMpeg dev's to test and optimize new code,im not aware you did.

 i know x264/FFMpeg assembly and C Dev's would have liked to have got feedback and access to real silicon a lot earlier , certainly before the PR web reviewers got access to this same silicon for review.

come to that , did you even think to setup some remote SSH to ALL your latest and greatest prototype boards and give these x264/ffmpeg dev's accounts, perhaps you should do at least that ASAP to at least give people something to actually work on and give feedback in the very productive and Fast moving x264 dev and FFmpeg dev IRC channels etc.

forgetting the CPU core section for the moment, wheres the new and improved microcode SAD/SATD and related instructions (that DS is always explaining are missing from gfx cores so cant be used alongside the CPU) placed inside the gfx core SIMD sections to actually help x264 dev's use the internal Gfx acceleration and feed it back to the CPU as fast as possible

[Dark Shikari]

"I am Francois Piednoel , Senior Performance analyst at Intel Corp Santa Clara ...
I am known for some Instruction designs, skulltrail, and few other gadget, I worked on LDDQU and MPSADBW etc ... and putted some magics into few hardware piece when giving feedback during the design of the CPUs.I am finalizing a prototype of x264 using the acceleration of Sandy Bridge, the next generations of Intel Processors."

and theres your problem Right there "and putted some magics into few hardware piece when giving feedback during the design of the CPUs."

Where exactly were YOU and related designers when actually designing this kit and thinking of new microcode and algorithm's to use ?

as far i as i know, you did NOT even Once ask the world class x264 assembly dev's what new hardware assisted microcode they might like to see , Help You create and TEST to make x264 and other type Encoder problem's better and faster , not to mention actual visual Quality based.

 it seems now's not the time to come asking for Software help and insight into fixing the real work data throughput problems that you may find are now surfacing and will do in the future, did you or the person reasonable for that task, even bother to automatically ship any new prototype silicon and boards to the x264/FFMpeg dev's to test and optimize new code,im not aware you did.

 i know x264/FFMpeg assembly and C Dev's would have liked to have got feedback and access to real silicon a lot earlier , certainly before the PR web reviewers got access to this same silicon for review.

come to that , did you even think to setup some remote SSH to ALL your latest and greatest prototype boards and give these x264/ffmpeg dev's accounts, perhaps you should do at least that ASAP to at least give people something to actually work on and give feedback in the very productive and Fast moving x264 dev and FFmpeg dev IRC channels etc.

forgetting the CPU core section for the moment, wheres the new and improved microcode SAD/SATD and related instructions (that DS is always explaining are missing from gfx cores so cant be used alongside the CPU) placed inside the gfx core SIMD sections to actually help x264 dev's use the internal Gfx acceleration and feed it back to the CPU as fast as possible

To be fair, they did at least contact Loren (even if it was merely an introduction); it's quite possible that further contact was made difficult due to corporate bureaucracy.

[drwho?]

To be fair, they did at least contact Loren (even if it was merely an introduction); it's quite possible that further contact was made difficult due to corporate bureaucracy.

wow ... That is quite an agressive set of answers ... Take it easy guys, You are kind of shooting at me for trying to talk to you, because we did not earlier ... See the chicken and egg issue here ? ;-)

Here is the situation, For the moment, the Sandybridge performance on video encoding is much faster than anything you can throw at it ... It was a pocker game with our competitor, not to show the real performance too early, and not to explain how the amazing performance works.

For Most of the world, SandyBridge acceleration will be accessable through mediaSDK , because it is the easiest way to do it.
After taking with Loren, one thing was very clear, He was totally clear that the x264 community would not include a call to a DLL without any control of the encoding process. I understood his point, and toke on myself to go and try to get the autorization to turn around MEdiaSDK and give you guys direct access (That mean to the world) to the Magic of SandyBridge. Trust me, i got a lot of heat out of it.

One thing for sure, I am smoking the GPUs on encoding itself ;-) by some serious factors ...
Now, I really want to get this out of the door, and get the Users of x264 to enjoy a good and fast encoding with massive power saving.

While talking to loren, I understood as well that quality is the prime directive. So, I archived to be extremely close.
Pa
Now for those interested, just email me, for the others ... well, it is ok to ignore me, just understand that I am the guy trying to open the Box ... ot the one who kept it closed.

Francois
PS: Remember, I can't fix all the misery of the World ... Video encoding is my passion, I optizimed DivX with Gej a long time ago, I worked with Al Mayo for many years, I talk to many of the codec guys .. Just trying to help who ever want to go faster, now, you have my email, go for it!

[Dark Shikari]

wow ... That is quite an agressive set of answers ... Take it easy guys, You are kind of shooting at me for trying to talk to you

No, we're asking you to fix the problem by contacting us now with more detail.  I even told you where to go (#x264dev), but you still haven't shown up.  We welcome your contributions, and we'd like to see Intel being more open about their technology.

, because we did not earlier ... See the chicken and egg issue here ? ;-)

Here is the situation, For the moment, the Sandybridge performance on video encoding is much faster than anything you can throw at it ... It was a pocker game with our competitor, not to show the real performance too early, and not to explain how the amazing performance works.

For Most of the world, SandyBridge acceleration will be accessable through mediaSDK , because it is the easiest way to do it.
After taking with Loren, one thing was very clear, He was totally clear that the x264 community would not include a call to a DLL without any control of the encoding process. I understood his point, and toke on myself to go and try to get the autorization to turn around MEdiaSDK and give you guys direct access (That mean to the world) to the Magic of SandyBridge. Trust me, i got a lot of heat out of it.

One thing for sure, I am smoking the GPUs on encoding itself ;-) by some serious factors ...
Now, I really want to get this out of the door, and get the Users of x264 to enjoy a good and fast encoding with massive power saving.

While talking to loren, I understood as well that quality is the prime directive. So, I archived to be extremely close.
Pa
Now for those interested, just email me, for the others ... well, it is ok to ignore me, just understand that I am the guy trying to open the Box ... ot the one who kept it closed.

Francois
PS: Remember, I can't fix all the misery of the World ... Video encoding is my passion, I optizimed DivX with Gej a long time ago, I worked with Al Mayo for many years, I talk to many of the codec guys .. Just trying to help who ever want to go faster, now, you have my email, go for it!

All you have to do is drop by #x264dev and get involved!  No need to hide in the corner.

amazing performance

"400fps iPod encoding" is now amazing performance?  Maybe if it was still 2001...

Of course, if the crappy numbers are the fault of Anandtech being retarded, I can fully understand that as well.  Anyone testing a video encoder by downscaling 1080p to 360p is pants-on-head retarded.

[aegisofrime]

drwho?/Mr. Piednoel, I just want to clarify some confusion I have. When you say,

"Here is the situation, For the moment, the Sandybridge performance on video encoding is much faster than anything you can throw at it"

are you referring to the new video encode engine or the Sandy Bridge CPU itself?

Now, I really want to get this out of the door, and get the Users of x264 to enjoy a good and fast encoding with massive power saving.

As a user of x264 and with Sandy Bridge as my next possible CPU, I would love to see the improvements you speak off

"400fps iPod encoding" is now amazing performance?  Maybe if it was still 2001...

I'm guessing English is not his first language, because it's not very clear whether he's talking about the onboard transcode engine or Sandy Bridge's CPU itself. The CPU is fast, that's for sure.

[kidjan]

All you have to do is drop by #x264dev and get involved!  No need to hide in the corner.

He's probably "hiding in a corner" after having his work belittled and efforts derided.  I'm sorry, but it is disrespectful to open a dialog with someone by stating that their work is "utterly useless" (even if it is) and wondering aloud why he personally did not inquire with x264 devs about Intel's microchip design.

Just my $.02; if you want this forum to be tangibly different from the one most of you have just left, how about a little respect?  Or at least a bit of tact?

[drwho?]

I am trying to open it up, let s all be nice with each other, and the x264 users will get good benefits ...
400fps ... hehehe , well, I am much faster than that ... much much much faster than this.

again, I am trying to get the community up to speed, before I totally open the code, I am trying to find a list of people interested to review the code with me, and put the community foot print on the top of this.

I am not trying to impose anything, and getting few people from all the forums is the best way to get every body to agree.
I was told I can find good coders in here, so, here I am , asking for inputs from here.

Francois

[patrick]

drwho? Thanks for staying at the thread, after the cold welcome.

Personally, I don't really care about 400 or 4000fps doing an iPod encoding. I think what really matters is the speed using extreme settings. Using fast settings, my hard disk will be a problem before my CPU (Intel i7).
So a speedup of video at 1080p using at least placebo settings would be nice

[Dark Shikari]

I am trying to open it up, let s all be nice with each other, and the x264 users will get good benefits ...
400fps ... hehehe , well, I am much faster than that ... much much much faster than this.

again, I am trying to get the community up to speed, before I totally open the code, I am trying to find a list of people interested to review the code with me, and put the community foot print on the top of this.

I am not trying to impose anything, and getting few people from all the forums is the best way to get every body to agree.
I was told I can find good coders in here, so, here I am , asking for inputs from here.

#x264dev is where development happens.  If you're looking for developers to review code with you, that's where you should go.  Seriously, is the port blocked on your network or something?  I mean, if there's something stopping you, say so, and we can arrange some method of bypassing the problem.

He's probably "hiding in a corner" after having his work belittled and efforts derided.  I'm sorry, but it is disrespectful to open a dialog with someone by stating that their work is "utterly useless" (even if it is) and wondering aloud why he personally did not inquire with x264 devs about Intel's microchip design.

First of all, note the wink: that statement was not entirely serious.  Secondly, if something you do is useless, that should surely give you even more reason to talk with developers before doing something new, in the hopes that the new thing be less useless.

Also, MPSADBW was a particularly ridiculous example, as not only was it beyond useless, but Intel teamed up with direct competitors of us (DivX) as part of a massive marketing campaign to lie about how useful it was (by using a badly implemented exhaustive motion search that nobody would use in a real encoder).  This resulted in an entire generation of users convinced that SSE4 made video encoding twice as fast, even though that's physically impossible, as not even half the time in encoding is spent in fullpel motion estimation, the area where MPSADBW would be used.  So even if MPSADBW made all motion estimation literally instant, it still would not have been able to satisfy the expectations created by this terrible marketing.  I was bitched at for years by people asking me to "implement SSE4 optimizations in x264" because of this.

Obviously, though, engineers are not at fault for the stupid actions of marketing.

Anyways, I'd love to get something interesting done here, but it's rather hard when there's absolutely no information whatsoever beyond "I have lots of cool toys, and I'm not sharing them with anyone!"

Can we at least have some API documentation or something?  

[multicast]

its not exactly hard to get to the IRC channels if you dont happen to have an IRC app handy, or even if the standard IRC ports are blocked, as theres always generic web IRC clients such as http://webchat.freenode.net/

enter your required name and #x264dev as the channel your interested in and type the catcha , done

[drwho?]

I guess, the admin of this forum has no interest to work with me, and well, it seems that I am a big lier by default.

For MPSADBW, well, I worked with the DivX guys for years, I don't think DivX and x264 are competing, Just 2 codecs, Interesting choices in both codecs.
In the case of MPSADBW, This instruction was design to increase the thoughput of SAD you can do paired with POSMIN instructions, every time I spent time to implement it somewhere, it paid back on the motion estimation. Let's say that you really want to find a good match, as the hollywood guys do in Blueray encoding, then, MPSADBW actually does much more in the same number of cycle.
I was told in the past that x264 could not increase its throughput with MPSADBW, and since we are on the subject, I am very interested to understand why.
Usually , using MPSADBW requires to make your motion search pattern more square, and 4x the Diamond size, or the area around your motion predicators and be done for free with MPSADBW and PHMINPOSUW. The common mistake does when looking at those 2 instructions is to think that you can get better throughput without changing your ME patterns. Basically, you get more Somme of Abs difference done in the same amount of cycle, and you get a very fast lower value pointer using PHMINPOSUW.

I guess, I m not welcome here, I got accused of many "lieing" on so on, sorry if I have bothered you ... I am better move on to other forums.
Take it easy.

[Dark Shikari]

I guess, the admin of this forum has no interest to work with me, and well, it seems that I am a big lier by default.

Actually, I've asked you about 6 separate times to come work with us!  You have refused every single time!  You have ignored my repeated emails and my pleas to come join us.

I was told in the past that x264 could not increase its throughput with MPSADBW, and since we are on the subject, I am very interested to understand why.
Usually , using MPSADBW requires to make your motion search pattern more square, and 4x the Diamond size, or the area around your motion predicators and be done for free with MPSADBW and PHMINPOSUW. The common mistake does when looking at those 2 instructions is to think that you can get better throughput without changing your ME patterns. Basically, you get more Somme of Abs difference done in the same amount of cycle, and you get a very fast lower value pointer using PHMINPOSUW.

I can explain the details if you drop by #x264dev.  The reasons are actually rather subtle.

I guess, I m not welcome here, I got accused of many "lieing" on so on, sorry if I have bothered you ... I am better move on to other forums.
Take it easy.

I have told you about half a dozen times that you are welcome here, and I want you to drop by IRC and get involved.  You have repeatedly ignored me!

It appears that I am the one who is not welcome.  I ask over and over and over again, and you refuse me every single time.  Why?  Why?  Why?  You come here, say you will work with us, but then you refuse to work with us!  You then continue to say you will work for us, while simultaneously refusing to do so!

I am completely lost as to what you are trying to do.  Here's a short summary, from my perspective, of your actions here:

Intel: We want to help!
x264: We'd be happy to accept help.  Come help us!
Intel: No, we refuse to help you!  But we want to help!
x264: MY BRAIN IS MELTING

Maybe it isn't quite obvious, but this is a tech-support forum.  Development of x264 occurs on IRC, not here.  Merely posting here does not get you involved in development; you need to come where the development actually happens.

[Bi11]

Intel: We want to help!
x264: We'd be happy to accept help.  Come help us!
Intel: No, we refuse to help you!  But we want to help!
x264: MY BRAIN IS MELTING

Piednoel: We want your help!
Glaser    : We'd be happy to accept help.  Come help us!
Piednoel: We'd be happy to accept help.  Come help us!
Glaser    : MY BRAIN IS MELTING
Piednoel: My lawyer wants NDA! (maybe one of many possibilities)

[Dark Shikari]

Piednoel: We want your help!
Glaser    : We'd be happy to accept help.  Come help us!
Piednoel: We'd be happy to accept help.  Come help us!
Glaser    : MY BRAIN IS MELTING
Piednoel: My lawyer wants NDA! (maybe one of many possibilities)

Heh, that's possible as well, but I'm not sure what Intel wants me to help them with.  They seem to be asking to contribute to x264, not the other way around.  I don't think they need my help designing chips!

[aegisofrime]

I'm disappointed at this outcome. There's no doubt that cooperation could have gave birth to great things for both Intel and x264. Unfortunately sometimes forums aren't the right venue for certain serious discussions.

[Dark Shikari]

I'm disappointed at this outcome. There's no doubt that cooperation could have gave birth to great things for both Intel and x264. Unfortunately sometimes forums aren't the right venue for certain serious discussions.

I'm already pushing hard using more official channels (at my workplace) to force Intel to come clean and be cooperative regarding the Sandy Bridge encoding cores.  They will not be able to justify hiding such information from a company they invested in.

I am not going to let one uncooperative Intel employee sabotage our hopes of gaining whatever benefit there is to be had from the new hardware.

[Sharktooth]

An intel engineer... uhm. I think he's faking his identity or just an incompetent troll (you can't seriously think some useless SSE4 instructions will speed up encoding so much... no way...) intel should fire immediately (and Francois Piednoel is definatly not...).

OR

he can't read english and/or doesn't understand it very well (possible since in his previous posts he made a lot of spelling mistakes coz he's french BUT looking at one of his video interviews, the real Francois Piednoel, french accent apart, understands and speaks english pretty well using correct words).

i think the first is the correct one.
however i can be completely wrong but i have a lot of other reasons to think he's a fake...

[drwho?]

I 'll provide every thing to Loren.

thanks,

Francois

[aegisofrime]

I 'll provide every thing to Loren.

thanks,

Francois

Please don't give up! As you might know x264 is used as a CPU benchmark by many websites. If x264 can be optimized for Sandy Bridge it will be of great value to you against AMD

[drwho?]

Please don't give up! As you might know x264 is used as a CPU benchmark by many websites. If x264 can be optimized for Sandy Bridge it will be of great value to you against AMD

well, I am just one employee of Intel, seem that it is compeling to some to dump their unhappy thoughts about Intel on me ;-)

hhehehhe ... do not get paid for that ;-)

don't worry, I ll provide the all source code and I will fly to meet Loren when he is available. I just wished we could have more people involved into this, after all, it is a really cool technology, and I did kill myself to get this to work, without any black box.

What IRC client do you use for freenode ... my regular mIRC client does not connect to it.

Nothing personal.
PS: Seriously, I got no email in my inbox, don't know where those 6 emails are, not even in my SPAM filter.

Francois

[Sharktooth]

there are plenty of free irc clients for windows but try with /connect irc.freenode.net in your irc client.

[Sharktooth]

xchat: http://code.google.com/p/xchat-wdk/wiki/InfoXChat?tm=6

[Dark Shikari]

well, I am just one employee of Intel, seem that it is compeling to some to dump their unhappy thoughts about Intel on me ;-)

hhehehhe ... do not get paid for that ;-)

don't worry, I ll provide the all source code and I will fly to meet Loren when he is available. I just wished we could have more people involved into this, after all, it is a really cool technology, and I did kill myself to get this to work, without any black box.

What IRC client do you use for freenode ... my regular mIRC client does not connect to it.

Nothing personal.
PS: Seriously, I got no email in my inbox, don't know where those 6 emails are, not even in my SPAM filter.

Francois

I emailed the email account you used to register for these forums (as listed on your profile info).  If you really haven't been ignoring me and there's just some fail technical problem, I apologize.

I'll be waiting on IRC!

[Dark Shikari]

And for those reading this thread but not watching IRC -- everything is worked out.  See how easy that was?

[drwho?]

And for those reading this thread but not watching IRC -- everything is worked out.  See how easy that was?

youpi!

Francois ---> ZZZZZZZZZZZZzzzzzzzzzzzzzzz (in bed)

[Sharktooth]

it seems i was wrong, so i apologize.