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
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.
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.
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.
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.
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."
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...
"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".
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.
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...
From my humble experience, "marketing" staff often lack tech knowledge beyond the surface of power-point slides. Those who do, are "shielded" from the outside. I'm sure Anand is familiar with this, but there's not an awful lot he can do about it.
Anyway, I would like to thank Anand and staff for writing articles of such high caliber. I'm truly impressed with what you guys are doing!
It makes no sense. Sure you can't use the integrated graphics output as P67 doesn't have support for the motherboard DVI/HDMI connectors, but if Quick Sync runs on the CPU why wouldn't you be able to use it? Seems like it still goes through the graphics drivers and thus is disabled if you use a discrete GPU. Did they not want to add new instructions for the encoding/decoding as they did with AES-NI? Maybe there's no space for them...
If my guess on how this works is correct the Lucid solution should also work on P67, unless the GPU and the video encode/decode circuits are permanently shut down on P67 with no way to turn them on again.
Basically anyone doing video editing can't use a discrete graphics card until this solution is in place, otherwise they can't use Quick Sync. If you also do 3d modeling or gaming that seems like a really bad design decision on Intel's part.
This might even mess up laptops with discrete graphics that do not have the Lucid solution, unless the mobile chipsets do allow the encoders and decoders to be running in such a case.
I don't think you have to worry about laptops, since they already have switchable graphics solutions. The only problem might be an Intel Chipset with an AMD graphics card.
On the post earlier, I wasn't knocking the guy for not knowing. If I remember right, he is lead engineer of the Sandy Bridge project. I was just wondering why he gave a definite "no" on switchable graphics for desktops. In my opinion, switchable graphics on a desktop (especially with the new Quick Sync technology) is a huge selling point. I guess the real question I was asking is how close does Intel work with 3rd parties when designing their hardware?
I thought quick sync was part of the igp area of the SNB chip and that's why it won't work without the igp enabled. That's what I took the article here on anandtech to mean anyway.
Yep. But why do you have to turn the IGP off? Just leave it on for encoding / decoding work without using it for any display. I don't see why that would require a third party software pack, unless Intel just doesn't care.
i don't think it can even be turned on and off on the p67 chipset, it's just off-off all the time, like the motherboard traces don't even involve the igp portion of the cpu or they are designed not to utilize them. i think it has something to do with the i/o available from the chipset/cpu, so they can make the PCIE 8x/8x available. it's a, what do you call it, trade-off.
My biggest gripe with this launch of SNB was how little this mobo-incompatibility issue was really fleshed out. in all the articles by Jarred/Anand it's mentioned here and there but the magnitude of basically there being NO options currently for the typical enthusiast that wants to OC and encode (with a discrete GPU) is just inexcusable.
The conclusion and intro of these articles should have big bolded comments saying, "If you are interested in OC your chip and encoding with a discrete GPU come back in 6 months".
Do I think SNB is fantastic? Yes. Do I think the mobo/cpu issue negates the former for desktop use? Also yes.
Please guys, make this readily known to your readers because I would hate for someone to miss this and build a system assuming they can use their great new gaming system as an encoding juggernaut only to find out they can't and need to shell out another $150-250 when the Z68 comes out.
Yeah I think Intel swept this under the rug a bit. "Quick Sync is awesome! You just can't use it with a dedicated GPU... Or with overclocking... Or with any P67 motherboard..." The same should be true for HD hardware decoding.
ya this is a big deal, and it wasn't emphasized in the 2500k/2600k article.
one of the main reasons I am interested in sandy bridge is for the accelerated video encoding. i was planning on buying a whole new setup this sunday at microcenter. but they only have P67 boards which are immediately obsolete, apparently.
wtf intel? ok well if i have to wait for Z68 or ivy bridge then i'll also have time to evaluate AMD bulldozer.
I'm also waiting for Z68 due to this. And due to the fact that I want switchable graphics on my desktop.. and at least keep the option open to get it via some software solution.
I guess I tell everyone to wait for Z68. Personally my current computer is fast enough that I'm waiting for 2012 to build anew. But if Intel can get everything right on Z68 then I can be optimistic about the next CPU refresh, which hopefully won't involve a new socket. Quick Sync is really impressive. Lucid, is quickly becoming one of my favorite companies in the world. They just do awesome work.
Will it be possible to use all 4 cores (8 threads) to software transcode video while simultaneously using Quicksync? Are any developers working on maximizing output from both parts of the cpu?
I dont know about anyone else, but I'd feel pretty silly if I spent $300 on a cpu just to have it sit mostly idle while it plugs away at my video. Even if a tiny little portion of the chip is built for transcoding, I'd still want to push my cpu cores to the maximum possible limit. Also, what about using the EU's to help? If you could encode a clip using x86 in 3 minutes, and if you could also encode that same clip using Quicksync in 2 minutes, then at least in theory you could use both to encode the clip in 80 seconds. And if you used the EUs, you could theoretically push that time down to around 70 seconds or so. So now we're talking about roughly doubling the output of Quicksync by fully utilizing the entire cpu.
That Intel would only put the top-of-the-line HD3000 in the K series! So you put the best integrated video on the only overclockable chips but then can't be overclocked on motherboards that support integrated video. WTF....
Since the picture is copied to the integrated GPUs memory, would this also open up the possibility of using the iGPU to do post-process anti-aliasing on the picture before it is sent out to the monitor? The GPU in Sandy Bridge should be fast enough to run pixel shaders needed to implement something like this: http://iryoku.com/mlaa/
This could also negate the performance hit from copying the image from the graphics card to system memory. Only problems remaining then would be the wait for Z68 and the tiny amount of lag the Lucids system might cause.
This will give a 1-3% impact on performance in what direction? No matter the direction, with such a small impact on performance, what advantage does this give?
Almost certainly that means that with lucids solution quicksync will only run at 97-99% of full speed. Which is still several times faster than the discrete GPU doing everything else graphics related in the system,.
Just have both GPUs on, render on the discrete one and transfer the buffer via pci-express to the IGP (shared RAM). 2.0 x16 PCI-e has a bandwidth of 8GB/s and 1920x1080@60 fps is just like 356MB/s. You should not need any additional hardware.
So most monitors today have more than one video input. In theory you could mirror the desktop to show on two screens (well, the same screen but different video inputs so the computer thinks it's two screens) with one through the discrete card and one through the Integrated Graphics on Sandy Bridge.
I think you guys at AnandTech should give that a try since you have hardware, and let us know if it's possible.
If you can do this then you would be able to use QuickSync while also using a discrete card.
Please! This! I would much rather have to "look" for a monitor with multi-inputs than install extra software for something that *SHOULD* be accomplished with the hardware of the system.
"Took the words right out of my mouth" or "This dude beat me to it"
and
"I can't even begin to explain how wrong you are so I wont even try"
There are a lot of smart people here that I'm sure can come up with far more clever ideas. But seriously, I needed something akin to that first button 3 times in the first page and a half, alone! (Something better than "I second that" or "Agreed"). Happy to say I have almost NO use for the second button, most days:)
Well seen as this just a software solution this opens up the possibility that developers will be able to switch on the IGP whilst a discreet GPU is in plugged in for thier applications - shouldn't be that hard to figure out seen as someone has done it already.
I suspose becuase it's talking to hardware it would tur it into a driver and thus need signing - hmm.... I wonder wether NVIDIA or AMD will release GPU drivers that will enable this?
I've been watching these articles with interest. But my understanding is that for top quality archival encodes, I would ALWAYS use avisynth and feed that into x264.
Does this encoder rival x264 in terms of quality per bit? Can avisynth frameserve to this encoder? And ideally can it be cmd line driven so that it can be part of a managed workflow? Any doom9 guys on here? And the overall encoding time will not speed up so dramatically if my avisynth script has decent motion compensated noise removal as that won't be accelerated unless all the good avisynth plugins are made to be gpu accelerated...
So my conclusion is this really is just for ppl who just want to convert something they downloaded so they can watch it on a phone or other small device.
I've come to essentially the same conclusion. For people doing serious video work, sacrificing quality for speed is not a direction they are looking to go into. Of course, it all depends on the intended destination (Big screen TV or youtube video). I'd actually be more interested in technology that improves quality at a given file size, even if it took longer to encode.
People who just want to put home video/rips onto their iphone/droid, or are trying to rip thier dvd/blueray collection as fast as possible are a much larger group; quicksync is perfect for them.
A possible TS support call if a user adds a discrete card and can't figure out to switch the monitor cable? And that assumes the software is already installed and will automatically configure itself.
Power reduction? We are talking about less than 10 watts idle difference between IGPs and modern discrete cards, and load power is quite close to for 2D/desktop/video decoding tasks.
Easier switchable graphics on laptops? This seems like the only place it's worthwhile, if a vendor can add switchable graphics with any mobile discrete.
Why can't the Sandybridge desktop boards include a DVI/HDMI input port to do passthrough from for switchable graphics. Is it an HDCP renegotiation issue we have the MPAA to thank for?
Thinking the same thing and willing to bet you are probably pretty close on the reasoning. I remember having a 2D Diamond (remember that company!) card daisy-chained to the first generation 3D Voodoo card on one of my first gaming rigs.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
Facebook
Twitter
RSS
44 Comments
Back to Article
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. loltipoo - 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...marc1000 - Friday, January 7, 2011 - link
i second your opinion... LOLzodiacfml - Friday, January 7, 2011 - link
useless, really. there's more information in Anandtech articles.soydeedo - Friday, January 7, 2011 - link
Yeah, I felt bad for the guy.MrSpadge - Saturday, January 8, 2011 - link
Agreed. After reading Anands SNB review I thought "I could have done better than the Intel guy". Well, thanks for trying anyway :)MrS
Robert Kooijman - Friday, January 7, 2011 - link
From my humble experience, "marketing" staff often lack tech knowledge beyond the surface of power-point slides.Those who do, are "shielded" from the outside.
I'm sure Anand is familiar with this, but there's not an awful lot he can do about it.
Anyway, I would like to thank Anand and staff for writing articles of such high caliber. I'm truly impressed with what you guys are doing!
DesktopMan - Friday, January 7, 2011 - link
It makes no sense. Sure you can't use the integrated graphics output as P67 doesn't have support for the motherboard DVI/HDMI connectors, but if Quick Sync runs on the CPU why wouldn't you be able to use it? Seems like it still goes through the graphics drivers and thus is disabled if you use a discrete GPU. Did they not want to add new instructions for the encoding/decoding as they did with AES-NI? Maybe there's no space for them...If my guess on how this works is correct the Lucid solution should also work on P67, unless the GPU and the video encode/decode circuits are permanently shut down on P67 with no way to turn them on again.
Basically anyone doing video editing can't use a discrete graphics card until this solution is in place, otherwise they can't use Quick Sync. If you also do 3d modeling or gaming that seems like a really bad design decision on Intel's part.
This might even mess up laptops with discrete graphics that do not have the Lucid solution, unless the mobile chipsets do allow the encoders and decoders to be running in such a case.
goozira - Friday, January 7, 2011 - link
I don't think you have to worry about laptops, since they already have switchable graphics solutions. The only problem might be an Intel Chipset with an AMD graphics card.On the post earlier, I wasn't knocking the guy for not knowing. If I remember right, he is lead engineer of the Sandy Bridge project. I was just wondering why he gave a definite "no" on switchable graphics for desktops. In my opinion, switchable graphics on a desktop (especially with the new Quick Sync technology) is a huge selling point. I guess the real question I was asking is how close does Intel work with 3rd parties when designing their hardware?
yvizel - Friday, January 7, 2011 - link
He cannot be a lead engineer of the Sandy Bridge project since it was designed in the Israeli site.softdrinkviking - Friday, January 7, 2011 - link
I thought quick sync was part of the igp area of the SNB chip and that's why it won't work without the igp enabled. That's what I took the article here on anandtech to mean anyway.DesktopMan - Friday, January 7, 2011 - link
Yep. But why do you have to turn the IGP off? Just leave it on for encoding / decoding work without using it for any display. I don't see why that would require a third party software pack, unless Intel just doesn't care.softdrinkviking - Friday, January 7, 2011 - link
i don't think it can even be turned on and off on the p67 chipset, it's just off-off all the time, like the motherboard traces don't even involve the igp portion of the cpu or they are designed not to utilize them.i think it has something to do with the i/o available from the chipset/cpu, so they can make the PCIE 8x/8x available.
it's a, what do you call it, trade-off.
7Enigma - Friday, January 7, 2011 - link
My biggest gripe with this launch of SNB was how little this mobo-incompatibility issue was really fleshed out. in all the articles by Jarred/Anand it's mentioned here and there but the magnitude of basically there being NO options currently for the typical enthusiast that wants to OC and encode (with a discrete GPU) is just inexcusable.The conclusion and intro of these articles should have big bolded comments saying, "If you are interested in OC your chip and encoding with a discrete GPU come back in 6 months".
Do I think SNB is fantastic? Yes. Do I think the mobo/cpu issue negates the former for desktop use? Also yes.
Please guys, make this readily known to your readers because I would hate for someone to miss this and build a system assuming they can use their great new gaming system as an encoding juggernaut only to find out they can't and need to shell out another $150-250 when the Z68 comes out.
DesktopMan - Friday, January 7, 2011 - link
Yeah I think Intel swept this under the rug a bit. "Quick Sync is awesome! You just can't use it with a dedicated GPU... Or with overclocking... Or with any P67 motherboard..." The same should be true for HD hardware decoding.austonia - Friday, January 7, 2011 - link
ya this is a big deal, and it wasn't emphasized in the 2500k/2600k article.one of the main reasons I am interested in sandy bridge is for the accelerated video encoding. i was planning on buying a whole new setup this sunday at microcenter. but they only have P67 boards which are immediately obsolete, apparently.
wtf intel? ok well if i have to wait for Z68 or ivy bridge then i'll also have time to evaluate AMD bulldozer.
MrSpadge - Saturday, January 8, 2011 - link
I'm also waiting for Z68 due to this. And due to the fact that I want switchable graphics on my desktop.. and at least keep the option open to get it via some software solution.MrS
Hrel - Friday, January 7, 2011 - link
I guess I tell everyone to wait for Z68. Personally my current computer is fast enough that I'm waiting for 2012 to build anew. But if Intel can get everything right on Z68 then I can be optimistic about the next CPU refresh, which hopefully won't involve a new socket. Quick Sync is really impressive. Lucid, is quickly becoming one of my favorite companies in the world. They just do awesome work.Shadowmaster625 - Friday, January 7, 2011 - link
Will it be possible to use all 4 cores (8 threads) to software transcode video while simultaneously using Quicksync? Are any developers working on maximizing output from both parts of the cpu?I dont know about anyone else, but I'd feel pretty silly if I spent $300 on a cpu just to have it sit mostly idle while it plugs away at my video. Even if a tiny little portion of the chip is built for transcoding, I'd still want to push my cpu cores to the maximum possible limit. Also, what about using the EU's to help? If you could encode a clip using x86 in 3 minutes, and if you could also encode that same clip using Quicksync in 2 minutes, then at least in theory you could use both to encode the clip in 80 seconds. And if you used the EUs, you could theoretically push that time down to around 70 seconds or so. So now we're talking about roughly doubling the output of Quicksync by fully utilizing the entire cpu.
Pneumothorax - Friday, January 7, 2011 - link
That Intel would only put the top-of-the-line HD3000 in the K series! So you put the best integrated video on the only overclockable chips but then can't be overclocked on motherboards that support integrated video. WTF....WeaselITB - Friday, January 7, 2011 - link
This.Hei. - Friday, January 7, 2011 - link
Since the picture is copied to the integrated GPUs memory, would this also open up the possibility of using the iGPU to do post-process anti-aliasing on the picture before it is sent out to the monitor? The GPU in Sandy Bridge should be fast enough to run pixel shaders needed to implement something like this: http://iryoku.com/mlaa/This could also negate the performance hit from copying the image from the graphics card to system memory. Only problems remaining then would be the wait for Z68 and the tiny amount of lag the Lucids system might cause.
ionis - Friday, January 7, 2011 - link
This will give a 1-3% impact on performance in what direction? No matter the direction, with such a small impact on performance, what advantage does this give?DanNeely - Friday, January 7, 2011 - link
Almost certainly that means that with lucids solution quicksync will only run at 97-99% of full speed. Which is still several times faster than the discrete GPU doing everything else graphics related in the system,.shtldr - Friday, January 7, 2011 - link
Just have both GPUs on, render on the discrete one and transfer the buffer via pci-express to the IGP (shared RAM). 2.0 x16 PCI-e has a bandwidth of 8GB/s and 1920x1080@60 fps is just like 356MB/s.You should not need any additional hardware.
DanNeely - Friday, January 7, 2011 - link
Lucid is doing this in *software*.naeonline - Friday, January 7, 2011 - link
So most monitors today have more than one video input. In theory you could mirror the desktop to show on two screens (well, the same screen but different video inputs so the computer thinks it's two screens) with one through the discrete card and one through the Integrated Graphics on Sandy Bridge.I think you guys at AnandTech should give that a try since you have hardware, and let us know if it's possible.
If you can do this then you would be able to use QuickSync while also using a discrete card.
arubino99 - Friday, January 7, 2011 - link
Please! This! I would much rather have to "look" for a monitor with multi-inputs than install extra software for something that *SHOULD* be accomplished with the hardware of the system.inaphasia - Friday, January 7, 2011 - link
Some suggestions:"Took the words right out of my mouth" or "This dude beat me to it"
and
"I can't even begin to explain how wrong you are so I wont even try"
There are a lot of smart people here that I'm sure can come up with far more clever ideas. But seriously, I needed something akin to that first button 3 times in the first page and a half, alone! (Something better than "I second that" or "Agreed"). Happy to say I have almost NO use for the second button, most days:)
billythefisherman - Friday, January 7, 2011 - link
Well seen as this just a software solution this opens up the possibility that developers will be able to switch on the IGP whilst a discreet GPU is in plugged in for thier applications - shouldn't be that hard to figure out seen as someone has done it already.I suspose becuase it's talking to hardware it would tur it into a driver and thus need signing - hmm.... I wonder wether NVIDIA or AMD will release GPU drivers that will enable this?
webs0r - Friday, January 7, 2011 - link
I've been watching these articles with interest. But my understanding is that for top quality archival encodes, I would ALWAYS use avisynth and feed that into x264.Does this encoder rival x264 in terms of quality per bit?
Can avisynth frameserve to this encoder?
And ideally can it be cmd line driven so that it can be part of a managed workflow?
Any doom9 guys on here?
And the overall encoding time will not speed up so dramatically if my avisynth script has decent motion compensated noise removal as that won't be accelerated unless all the good avisynth plugins are made to be gpu accelerated...
So my conclusion is this really is just for ppl who just want to convert something they downloaded so they can watch it on a phone or other small device.
nwrigley - Saturday, January 8, 2011 - link
I've come to essentially the same conclusion. For people doing serious video work, sacrificing quality for speed is not a direction they are looking to go into. Of course, it all depends on the intended destination (Big screen TV or youtube video). I'd actually be more interested in technology that improves quality at a given file size, even if it took longer to encode.DanNeely - Saturday, January 8, 2011 - link
People who just want to put home video/rips onto their iphone/droid, or are trying to rip thier dvd/blueray collection as fast as possible are a much larger group; quicksync is perfect for them.Jovec - Saturday, January 8, 2011 - link
What does this solve?A possible TS support call if a user adds a discrete card and can't figure out to switch the monitor cable? And that assumes the software is already installed and will automatically configure itself.
Power reduction? We are talking about less than 10 watts idle difference between IGPs and modern discrete cards, and load power is quite close to for 2D/desktop/video decoding tasks.
Easier switchable graphics on laptops? This seems like the only place it's worthwhile, if a vendor can add switchable graphics with any mobile discrete.
glugglug - Sunday, January 9, 2011 - link
Why can't the Sandybridge desktop boards include a DVI/HDMI input port to do passthrough from for switchable graphics. Is it an HDCP renegotiation issue we have the MPAA to thank for?7Enigma - Monday, January 10, 2011 - link
Thinking the same thing and willing to bet you are probably pretty close on the reasoning. I remember having a 2D Diamond (remember that company!) card daisy-chained to the first generation 3D Voodoo card on one of my first gaming rigs.