ASUS and Intel are putting together a webcast that they've invited me to attend. The topic of discussion? Sandy Bridge. The webcast will air after Intel's official announcement of Sandy Bridge at 9AM PST on January 5, 2011 at CES.

The discussion will be a conversation between myself, Gary Key (former AT Motherboard Editor, current ASUS Technical Marketing Manager), and Michael Lavacot, an Intel Consumer Field Application Engineer. 

If you have any questions you'd like to see me answer on air or that you'd like me to grill ASUS and Intel on, leave them in the comments to this post and I'll do my best to get them addressed.

Of course we will also have our full review of Sandy Bridge around the same time. 

Update: Intel posted some of the videos from this webcast on its YouTube channel. I tried to answer as many of the big questions you guys asked as I could in the video or in our Sandy Bridge review

I'll add links here for more videos as they get posted:

Comments Locked


View All Comments

  • marraco - Thursday, January 6, 2011 - link

    Please, can the videos be subtitled? (or a transcript added to the article?)

    I understand written English, but have big difficult into hearing English.
  • marraco - Thursday, January 6, 2011 - link

    An important question:

    x86 programming is well known by programmers, because the information is public, and anybody (prepared) can write a compilator.

    But most info on GPUs had being keep secret. That's why open source drivers for nVidia and ATI are much worse performers than the privative, closed ones.

    So, since Sandy Bridge GPU is part of the same chip, the million dollar question is:

    Will the information be widely available? Will it be as open as it is on CPU?

    I think that it makes nonsense to integrate the GPU on processor, and keep the old GPU practices.

    No portion of the chip should be keep hidden to the programmer, if Intel wants for it to be successful.

    It makes nonsense to be able to access freely some portions of the chip, and being forced to access the other only under an API.

    On other side, an API may enhance the portability to other architectures, and maybe Intel don't want to be constrained to keep compatibility with his present architecture, as is constrained to maintain obsolete x86 instructions to preserve compatibility.

    Also, opening the GPU architecture would enable nVidia and AMD to take advantage of it to enhance discrete cards performance, by allowing his drivers to run instructions on GPU processors. But Intel may prefer to hinder performance for competitor’s software.

    But if Intel keeps information away from programmers, then it makes nonsense to integrate the CPU. It's just a non upgradeable GPU wasting the thermal and power resources on the procesor. An inferior solution compared to discrete GPU and pure CPU.
  • mlavacot - Tuesday, January 18, 2011 - link

    Not as much as you want, at least not yet. You can assume we will start with API calls via Direct X, OpenGL and Open CL and then move to lower levels from there. Interesting thought on an open GPU architecture, but that is where the graphics chip vendors have their secret sauce. I think it will have to be abstracted to an API level for some time to get commonality.
  • marraco - Thursday, January 6, 2011 - link

    A GPU driver is a software layer made by the manufacturer, but for software to rely on it, it needs to preserve compatibility between generations.

    CPU generally don't depend on drivers (up to some extent), because CPU programmation is made by the operative system maker.

    There is any plan to make a standard common to Intel and AMD? GPGPU programming should be done by OS writters, as is donne by CPU. Otherwise Intel will find itself burdened by maintaining increasingly complex OS tasks. Are the plans to limit GPU programming and management to DirectX/OpenCL APIs?
  • CreativeStandard - Thursday, January 6, 2011 - link

    When are you going to have time to update the GPU bench with Intel's new built in GPU? May serve as a good baseline for the cards.
  • will2 - Thursday, January 6, 2011 - link

    I did ask in your Q&A on SB last week there was a dearth of info on specs, benchmarks, and release date for the 25W and 17 Watt TDP versions - but not answered, and today still see no answers to any of those things. Can you now supply whatever info you have on the specs, benchmarks and availability dates. The i7 2629M (25W) and i5 2537M (17W) are of particular interest, but any info on the Notebook LV & ULVs is of interest. Even something as basic as what speed of DDR3 - 1333 or 1600, should be well known by now.

    The only other thing I noticed sine my post last week, is a reference in 'theinquirer' or 'theregister' & elsewhere, to 'Sandy Bridge sucks in Hollywood DRM' - but few details. Interested to know the scope of the DRM built into the hardware and how pervasive its effect on usability of a pc built with SB
  • mlavacot - Tuesday, January 18, 2011 - link

    We do not comment on products that have not been released, so I recommend you go to for answers that are available. There is a lot if you dig around. Sorry.
  • inaphasia - Friday, January 7, 2011 - link

    You should have grilled him on the USB 3.0 question. And when did Intel wave their hand saying "you don't NEED USB 3.0 just yet", making a lot of people here actually believe it? I missed that part.

    Don't get me wrong, I don't need the speed either... But the power would be nice.
  • mlavacot - Tuesday, January 18, 2011 - link

    We would have loved to have USB 3.0 integrated into this processor, we just could not get it done in time. We will get there, just not yet. BTW, OEMs can integrate a USB 3.0 controller on their boards as a separate feature, it just costs a few bucks more and takes up some extra board space.
  • CSMR - Friday, January 7, 2011 - link

    The major problem for me with Intel HD graphics is driver quality. It's abysmal, to the extend that half the things that I try that are supposed to work don't.

    You mentioned MPC-HC does not work. For Clarkdale/Arrandale this was a problem with Intel not supporting DXVA using standard methods. I presume this is still a problem on Intel's side. You say "It's an issue with MPC-HC and not properly detecting SNB": could you elaborate on this? In Clarkdale/Arrandale the acceleration mechanism wasn't even documented, and it required an Intel engineer to work with MPC-HC in his spare time (without success).

    Could you test compatability with Photoshop CS5 too? Clarkdale/Arrandale support is described as "basic" by the application.

    Also color management does not work in Clarkdale/Arrandale; the LUT is perpetually reset.

    Also FastPictureViewer does not work on Clarkdale/Arrandale, despite working correctly in the reference DX implementation. There is corruption in rendering images.

    Are they going to make any progress with Sandy Bridge? Unfortunately it's hard to tell as reviewers are obsessed with games performance exclusively.

    It is possible to ask them about this?

Log in

Don't have an account? Sign up now