If you read our Sandy Bridge Review you’ll know that we were very excited about Intel’s Quick Sync hardware transcode engine. It easily offers at least twice the performance of existing GPU based transcoding solutions without sacrificing image quality. There’s just one little problem: you can’t use Quick Sync you're using a discrete GPU, you need to use Intel's processor graphics.

Lucid presented a potential solution to the problem at this year’s CES. Through software alone, Lucid is able to copy the frame buffer from a discrete PCIe GPU to the frame buffer of SNB’s HD Graphics in main memory. The result is that you can hook a single monitor up to your motherboard’s video output and use a discrete GPU when you want it. Lucid’s technology would enable switchable graphics on the desktop, without any hardware requirements (it still obviously won’t work on P67, shame on Intel).

To demonstrate the technology Intel ran an H67 motherboard with a GeForce GTX 480. Lucid’s software was installed which allowed for the GTX 480 to run and its frame buffer output to be copied to main memory and sent out via Intel’s Flexible Display Interface through the DVI port on the back of the motherboard. 

At the same time, Intel demonstrated that it could run a Quick Sync enabled transcode in Cyberlink’s Media Espresso 6 - all thanks to Lucid’s software.

Lucid expects that there will only be a 1 - 3% impact in performance (although that’s something we’d have to see for ourselves), but there’s no firm date on when the driver will be available. I’m expecting a beta version of Lucid’s software in the coming weeks however.

Motherboard manufacturers could bundle Lucid’s solution with their boards to avoid upsetting end users thanks to Intel’s Quick Sync oversight. There’s still no getting around the fact that you can’t overclock your CPU on H67 motherboards. You’ll still have to wait for Z68 to fix that problem.

Comments Locked

44 Comments

View All Comments

  • goozira - Friday, January 7, 2011 - link

    Anand, why couldn't the Intel guy answer the question of switchable graphics when you asked him in the interview? He could have said "Well, there might be a 3rd party solution in the future." Great interview, btw. I think you knew more about SNB architecture than he did. lol
  • tipoo - Friday, January 7, 2011 - link

    I thought he did answer that, with it being done already in laptops, but desktops were harder since the IGP and a discreet GPU would have different physical connections.
  • strikeback03 - Friday, January 7, 2011 - link

    That was the answer he gave, but it didn't answer whether there was the possibility to do something like what Lucid is doing here (or Optimus does on laptops) and copy the frame buffer from the discrete card to the IGP.

    And yes it also seemed to me like Anand was giving the Intel guy some information, not vice versa.
  • anactoraaron - Friday, January 7, 2011 - link

    keep in mind that he did say he had a masters in engineering but he's their marketing guy. He services people... and that means... he works with vendors and motherboard manufacturers... and... what he does is... uh... he uh... yeah. Marketing teams generally have no idea of what they are talking about when you deal in specifics and generally only know what their marketing points are. I second Anand knowing more than him about SNB. I lol'd when Anand corrected the guy.
    Intel should send someone that helped design the chip in question next time.
  • Greg512 - Saturday, January 8, 2011 - link

    If you are implying marketing teams do not do anything you are sadly mistaken. Good marketing, unfortunately, it what usually makes a product successful, not good engineering. Though I do agree, however, that it would have been wise to have a more knowledgable employee speak with Anand considering his websites more knowledgable audience.
  • medi01 - Friday, January 7, 2011 - link

    In SB review anand admits that Quick Sync (what a lame name) actually does sacrifice quality for speed. In this article we get: ".It easily offers at least twice the performance of existing GPU based transcoding solutions without sacrificing image quality."

    What did I miss?
  • Fallen Kell - Friday, January 7, 2011 - link

    You missed the point that it said "existing GPU based transcoding". All the GPU based transcoders sacrifice quality for speed. The CPU based transcoders are the ones which speed is sacrificed for quality. Go back and look at the article on it in here. Most people couldn't tell much of a difference at a glance between the transcoders, except for the Nvidia based GPY transcoder. That said, the CPU based transcoder was clearly the best image quality, with the ATI and Quick Sync solutions close together in terms of image quality, with Quick Sync taking half the time...
  • medi01 - Saturday, January 8, 2011 - link

    Maybe you've missed this part as well, citation:

    "The image quality story is about the same for AMD’s GPUs and the x86 path, however Quick Sync delivers a noticeably worse quality image. It’s no where near as bad as the GTX 460, but it’s just not as sharp as what you get from the software or ATI Stream codepaths."

    how did the "noticeable worse quality image" turn into "without sacrificing image quality" please?

    Not to mention that that "48% faster" and "71% faster" is not the same as "twice as fast".
  • Alexvrb - Saturday, January 8, 2011 - link

    Bingo. Quick Sync is Intel's new Fast n' Fugly technology. I would *never* use it for permanent encodes or archiving. Too big a quality hit. I'd rather throw more CPU cores at it and lose some speed - you can queue up work and the box can encode while you sleep anyway.

    However there ARE uses for Quick Sync. For non-permanent encodes, such as a quick sloppy conversion from HD content to SD content (for your phone or whatever), it is great! It is also good for dynamic re-encoding for streaming to various TV boxes. Such as using TVersity or similar to stream some advanced high bitrate H.264 profile stream to a box that can't handle that profile or bitrate.

    That would allow the Quick Path equipped machine to dynamically re-encode the video without eating up hardly any power/cpu cycles. Might not be bad for a video server in that case. Anyway, all of that hinges on software support.

    Either way, this won't kill software encoding any time soon. AMD's solution might, if quality is really as good as I've heard.
  • james.jwb - Friday, January 7, 2011 - link

    Well, I don't mean to sound mean, but he couldn't answer most of the questions put to him. Anand had to interrupt and give more updated information many times, discretely of course. It was slightly embarrassing to watch actually...

Log in

Don't have an account? Sign up now