[coreboot] [Patch] SSE & SSE2
joe at settoplinux.org
Wed Mar 17 01:02:11 CET 2010
On 03/16/2010 07:39 PM, Stefan Reinauer wrote:
> On 3/17/10 12:34 AM, Joseph Smith wrote:
>> On 03/16/2010 07:29 PM, Stefan Reinauer wrote:
>>> On 3/16/10 5:31 PM, Myles Watson wrote:
>>>> This patch selects SSE& SSE2 in the socket if one exists (except for
>>>> AMD since there are many sockets for two models).
>>>> The reasoning is that sockets can support multiple models of CPUS for
>>>> intel, and SSE& SSE2 settings need to be based on the least capable
>>>> It's all correct as far as Google tells me.
>>> Not as far as Wikipedia is concerned. I think we should be careful as
>>> this easily breaks the code in very nasty places (especially SSE chooses
>>> the registers for ROMCC, so this definitely breaks some boards)
>>> The settings have to be the most conservative, not the best possible.
>>> That means if there is a single CPU for a socket that does not have SSE,
>>> SSE has to be off for that socket. Choosing SSE to be on because there
>>> is a single CPU for that socket that has SSE will break other systems.
>>>> Slot 1 - SSE but not SSE2
>>> Slot 1 is used by Pentium II, but only Pentium III has SSE.
>>> Also, Celeron only has SSE starting from Coppermine. Covington and
>>> Mendocino don't have SSE.
>>>> Slot 2 - SSE but not SSE2
>>> I think this is also wrong. Slot2 was then Xeon slot, but it also
>>> started with Pentium II based CPUs, which do NOT have SSE.
>>>> Via C3 - SSE but not SSE2
>>> Only Nehemiah and newer have SSE. All Samuel, Samuel2, Ezra and Ezra-T
>>> CPUs don't.
>>> I stopped after checking three of the ones you changed, because all
>>> three are wrong.. I think the code should not be changed. It's likely
>>> that the whole table you were using to do the matching was not
>>> describing what we need but instead the "socket capabilities" (i.e. the
>>> biggest feature set usable with that socket)
>> Well then we are going to need a different solution......
> I think the code as it is works just fine. Ok, the warnings should be
> silenced, but that's about it.
> If someone is developing support for a new chipset and is using romcc
> (which is the only reason one would need SSE to be set), they'll find
> out what the best possible setting for their slot is, to avoid register
> pressure :) If the code compiles, there is not (much) gain in enabling
> SSE even if your CPU supports it.
> As for SSE2, the only time this is used is for increasing the speed of
> ram_check() which is normally not run.
> So if you guys think this needs fixing, go ahead, but please don't break
> things because it makes Kconfig look nicer. We just went into that trap
> for ROMCC itself a day ago.
Sorry my bad your right. I thought the whole point was to get rid of
SSE2 build warnings on model_6xx cpu's that don't support SSE2.
More information about the coreboot