Intel Ivy Bridge

Hat hier denn keiner einen Ivy Bridge, der mal ein 30kb Tools starten kann um den Ivy Bridge (Grafik-OpenCL) ins Boinc zu helfen ?!?!

Dass, was gebraucht wird, sieht in etwa so aus
Number of platforms: 1
Platform Profile: FULL_PROFILE
Platform Version: OpenCL 1.1 AMD-APP (851.4)
Platform Name: AMD Accelerated Parallel Processing
Platform Vendor: Advanced Micro Devices, Inc.
Platform Extensions: cl_khr_icd cl_amd_event_callback cl_amd_offline_devices


Platform Name: AMD Accelerated Parallel Processing
Number of devices: 1
Device Type: CL_DEVICE_TYPE_CPU
Device ID: 4098
Board name:
Max compute units: 1
Max work items dimensions: 3
Max work items[0]: 1024
Max work items[1]: 1024
Max work items[2]: 1024
Max work group size: 1024
Preferred vector width char: 16
Preferred vector width short: 8
Preferred vector width int: 4
Preferred vector width long: 2
Preferred vector width float: 4
Preferred vector width double: 0
Native vector width char: 16
Native vector width short: 8
Native vector width int: 4
Native vector width long: 2
Native vector width float: 4
Native vector width double: 0
Max clock frequency: 1795Mhz
Address bits: 32
Max memory allocation: 804241408
Image support: Yes
Max number of images read arguments: 128
Max number of images write arguments: 8
Max image 2D width: 8192
Max image 2D height: 8192
Max image 3D width: 2048
Max image 3D height: 2048
Max image 3D depth: 2048
Max samplers within kernel: 16
Max size of kernel argument: 4096
Alignment (bits) of base address: 1024
Minimum alignment (bytes) for any datatype: 128
Single precision floating point capability
Denorms: Yes
Quiet NaNs: Yes
Round to nearest even: Yes
Round to zero: Yes
Round to +ve and infinity: Yes
IEEE754-2008 fused multiply-add: Yes
Cache type: Read/Write
Cache line size: 64
Cache size: 65536
Global memory size: 804241408
Constant buffer size: 65536
Max number of constant args: 8
Local memory type: Global
Local memory size: 32768
Kernel Preferred work group size multiple: 1
Error correction support: 0
Unified memory for Host and Device: 1
Profiling timer resolution: 279
Device endianess: Little
Available: Yes
Compiler available: Yes
Execution capabilities:
Execute OpenCL kernels: Yes
Execute native function: Yes
Queue properties:
Out-of-Order: No
Profiling : Yes
Platform ID: 0116A4F4
Name: Mobile AMD Athlon(tm) 64 Processor 2800+
Vendor: AuthenticAMD
Device OpenCL C version: OpenCL C 1.1
Driver version: 2.0
Profile: FULL_PROFILE
Version: OpenCL 1.1 AMD-APP (851.4)
Extensions: cl_khr_fp64 cl_amd_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_gl_sharing cl_ext_device_fission cl_amd_device_attribute_query cl_amd_vec3 cl_amd_printf cl_amd_media_ops cl_amd_popcnt

nur halt mit Intel GPU-Daten .... und bitte hier posten
 
http://ht4u.net/news/25496_opengl-4..._ivy_bridge_verfuegbar_-_af-probleme_behoben/

Während die integrierten Grafikeinheiten HD 2500 und HD 4000 der "Ivy Bridge"-Prozessoren unter DirectX 10 bereits zum Launch einen sehr guten Eindruck bei aktivem anisotropen Filter hinterlassen haben, zeigte eben dieser unter DirectX 9 eine seltsame Eigenschaft. Bei Analyse der Winkelabhängigkeit tauchten bei 16-facher Filterung über das gesamte Sichtfeld hinweg "Spikes" oder "Fransen" im Filtertester auf. Da dieses Problem unter DirectX 10 nicht vorhanden war bzw ist, war schnell klar, dass es sich hierbei um ein Treiberproblem handeln muss.

Mit dem neuen Beta-Treiber mit der Endung 2729 hat Intel das Problem nun aus der Welt geschafft, so dass auch unter DirectX 9 der anisotrope Filter nahezu winkelunabhängig arbeitet.
Na immerhin. :)
 
Wie vermutet haben reichlich Leute ihre CPU's vom Heatspreader befreit und es scheint sich die von Intel verwendete Paste als Grund für höhere Temperaturen raus zu stellen.

Die Tester haben diese ausgetauscht und den HS wieder befestigt wo mit dann auch der Anpressdruck der Kühler wieder hingekommen ist und dann deutlich niedirige Temperaturen
unter Last bekommen.

http://www.3dcenter.org/
 
Schön dann liegt es nicht, wie von einigen Experten hier vermutet, am 22nm Prozess, sondern an ziemlich dümmliche Sparmaßnahmen seitens Intel. 8-(
 
Ja natürlich, es liegt auf jeden Fall nicht am 22nm Prozess. Da kann gar kein Zweifel bestehen:]


Gibt es denn Vergleiche mit einem i7-2700K(o.ä.)? (Ich weiß, das geht nicht wirklich, daher ist das eher eine rhetorische Frage)
Kann man sich wirklich sicher sein, dass bei SNB "bessere" TIM benutzt wurde?

Und der T Junction Wert bei den IVB Mobil-Prozessoren ist auch um 5° Kelvin erhöht, weil die (max.) gemessene zugelassene Kerntemperatur sich nicht erhöht hat, man wollte nur auf Nummer Sicherer gehen.


Fakt ist, die TIM bei IVB ist scheiße. Aber solange man keine Vergleichswerte mit anderen Prozessoren hat , kann man nicht einfach konstatieren: Es liegt nur! an der TIM.


Ihr checkt irgendwie nicht, dass das für IVB kein Problem darstellt etwas wärmer zu werden, unter normalen Bedingungen und Intel gibt auch keine Garantie auf übertaktete Prozessoren (außer man bezahlt dafür ;).

edit:

Ich zitiere aus dem IVB-Thread bei 3DCenter:
Ronny145

Geklärt ist da noch lange nichts. Wenn Sandy Bridge von einer besseren WLP prozentual im ähnlichen Maß profitiert, besteht das Hitzeproblem in Ivy Bridge dennoch. Der Test zeigt nur auf, dass durch eine bessere WLP die Temperatur von IVB stark abgesenkt werden kann. Ob Ivy Bridge/22nm größere Temperaturen entwickelt oder nicht, ist dadurch noch nicht erwiesen. Hierfür müssten andere CPUs der gleichen Prozedur unterzogen werden. Wenn der Temperaturanstieg wirklich nur durch eine minderwertige WLP verursacht wird, wäre das natürlich besser als ein generelles Hitzeproblem von Ivy Bridge bzw. der 22nm Fertigung.
 
Zuletzt bearbeitet:
SB ist aber verlötet da kann man es nicht gegenprüfen mit, ob es für weitere IB auch gilt was da in dem Versuch festgestellt wurde wird sich in Kürze zeigen. Es gibt da genug "Mutige".

Am Übertakten ändert sich trotzdem laut den Aussagen nichts, mit normaler Kühlung (auch Wasser) geht trotzdem nicht mehr. Da begrenzen wohl noch andere Faktoren.
 
Das habe ich bereits geschrieben, dass es nicht wirklich möglich ist.

Dennoch kann man nicht einfach durch einen Test einer CPU konstatieren, dass es an der TIM liegt. Das ist unseriös.

Es zeigt wie sich diese CPU verhält, wenn man bessere Wärmeleitpaste verwendet, man kann aber nicht von dem Verhalten einer CPU auf das Verhalten von Millionen von Chips extrapolieren. Und ich denke mal, dass die Leute bei PC Watch diese pauschale Aussage auch gar nicht getroffen haben.

Aber natürlich wird es gerne von den Medienkopierern übernommen und dann mit eigenen Kommentaren versehen, denn Japanisch kann offensichtlich kaum einer der internationalen Online-Redaktionen, genausowenig wie Chinesisch und sogar Englisch stellt viele Redaktionen vor Probleme.*lol*
 
Die Einsparungen zwischen 800MHz und 1200MHz sind sehr gering. Der freiwerdende P-State ist da an anderer Stelle sicher sinnvoller genutzt.
 
Wie kann man den P-State denn anderweitig sinnvoll nutzen?

Und bei den ULV-Varianten geht es ja noch dass sie bis 800MHz heruntertakten.

Ob die Verluste so marginal sind - ich weiß nicht. Habe mal Reviews zum x230 studiert, das Update vom x220. Da haben sich die Akkulaufzeiten anscheinend eher verschlechtert. Kann natürlich viele Gründe haben, ist mir jetzt nur in Verbindung mit dem Takt aufgefallen.
 
ich bin ja nun auch Besitzer eines Ivy Bridges (3820QM) und mit Throttle Stop 4.10 taktet er seltsamer Weise auf 800Mhz runter und ich erfahre keine wirklichen Vorteile.

Ich habe so im Idle lt. HWinfo 1,1-1,5W kurzeitig auch mal 2W für die Kerne. Mit 800 MHz hatte ich vllt im Schnitt 0,1W weniger, wenn überhaupt!

Ich muss aber sagen die mobilen Ableger werden mit ziemlich hoher Spannung betrieben! Also ich sehe bei 4,1GHz so 1,3V im Idle (Intel lässt ja bekanntlich 400MHz mehr zu beim 3720 und 3820QM)
In den Spezifkationen habe ich als maximale Spannung 1,35V gefunden. argiert also ziemlich am Limit.
Vllt. laufen sie deswegen alle so viel heißer.
Da ich aber die Leistungaufnahme nicht verstellen kann, sondern nur die Multis, habe ich unverändert bei Auslastung aller Threads gerade mal 3-3,2GHz bei 1,08-1,13V.
Temperaturen bewegen sich im unteren 80°C Bereich, in den ersten 28s, wo er scheinbar 55W verbrauchen darf, um die 87°C bei 3,4-3,6GHz (möglich wären 3,9GHz).
Bei Singlethread Auslastung bei 3,9-4,1GHz läuft er schon auf 97°C zu. Nur der Lüfter kommt so schnell nicht nach, denn der könnte noch höher.

Da ich keinen Heatspreader serienmäßig habe, konnte ich wegen eines Wärmeleitpastenwechsel ca 5°C "einsparen"
 
Zuletzt bearbeitet:
... Throttle Stop 4.10 ...

Danke für die Info zu diesem Tool, erinnert mich an RightMark, dass bereits der Ivy Bridge unterstützt wird, genial. Mein erster Test ging leider schief, ich konnte Multi 16 zwar einschalten, aber nicht mehr zurücknehmen. Das werde ich testen.
 
Naja unterstützt wird er noch nicht ;) er geht aber, weil Sandy Bridge eine weitgehend identische Architektur hat ;)
Ich würd mal sagen durch die Sockelkompatabilität sind (fast) alle Pins gleich belegt (PCIe 3.0) und daher wird es wohl gehen. Der Release ist nämlich von Anfang März.
Wird wohl nimmer lange dauern und dann geht auch Ivy Bridge damit tadelos.
Nur der TPL Button geht bei mir nicht.

BTW: Nur wenn HWInfo und Throttle Stop gleichzeitig laufen, habe ich die 800MHz....

Auf Akku ohne irgendwelche Einflüsse von Throttle Stop verbraucht er im Mittel nur noch 0,6W im Idle.. Also viel mehr kann man an den Kernen sowieso nicht sparen!
 
Zuletzt bearbeitet:
Für das 2. Quartal 2013 ist Haswell geplant, [...]
Wenn Intel mit den neuen Haswell-Grafiklösungen nur an LIano herankommt

Eine 22nm CPU mit Stacked RAM (=teuer) die Ende 2013 mit Hängen und Würgen an den Rücklichtern von AMDs APU von Ende 2011 klebt.... warum nur bringt mich diese Aussicht nicht um den Nachtschlaf?
 
Eine 22nm CPU mit Stacked RAM (=teuer) die Ende 2013 mit Hängen und Würgen an den Rücklichtern von AMDs APU von Ende 2011 klebt.... warum nur bringt mich diese Aussicht nicht um den Nachtschlaf?
Weil AMD ebenso in Zukunft RAM-Chips auf die APU "kleben" will - scheint wohl das nächste große "Ding" in der Halbleiterindustrie zu sein.

MFG Bobo(2012)
 
Irgendwann "klebt" Mouse, Tastatur und Bildschirm, dann schließlich auch der Nutzer noch mit drauf. ;)
Wer kann sich da dem technischen Fortschritt noch entgegenstellen?
 
Aber auch nur, wenn es AMD genauso gut/schlecht hinbekommt, wie der DRAM-Erfinder ;)
 
Du zitierst mich aus dem "Trinity nimmt fahrt auf Spekulations-Thread" und packst das hier rein? Okay.
Dann aber bitte vollständig zitieren, und da fehlt ja auch die Vorgeschichte aber das macht nichts, hier das vollständige Zitat:
Bis Trinity, wenn überhaupt auf breitem Feld (Desktop, Notebook, Ultrathins) verfügbar ist, schreiben wir das Jahr 2013...
Für Q2/2013 ist Haswell geplant, ebenfalls im 22-nm-Verfahren (wie IB) nur mit schnellerer iGPU mit eDRAM und zudem DirectX 11.1 und OpenGL 3.2 Unterstützung.
Wenn Intel mit den neuen Haswell-Grafiklösungen nur an LIano herankommt, hat sich das für Trinity doch eigentlich schon geschissen?
http://www.planet3dnow.de/vbulletin/showthread.php?t=404165&page=42
Eine 22nm CPU mit Stacked RAM (=teuer)
Das mag ja sein und auf die Preise bin ich im übrigen auch sehr gespannt, Vorteil von eDRAM liegt ja auf der Hand, Speicherbandbreite, das Kontra bei LIano und Trinity.
die Ende 2013 mit Hängen und Würgen an den Rücklichtern von AMDs APU von Ende 2011 klebt....
Mhhh... das sollte man eventuell mal abwarten, ich habe bewusste Wörter wie: wenn und nur gewählt, ich glaube nicht das Intel da LIano-Leistung anpeilt, sondern mehr.
warum nur bringt mich diese Aussicht nicht um den Nachtschlaf?
Ich weiß nicht? Vielleicht, weil man über Liano iGPU liegen kann und eventuell sogar über Trinity und es dann jenen Nachfolge schwerer haben wird?

Kein Ahnung, schauen wir mal auf Spielbenchmarks in 1366x768 und erkennen wo sich HD3000 und HD4000 ansiedelt, eher ganz weit unten.
Die Grafikleistung der großen LIano-iGPU liegt in Summe natürlich über HD4000 , Trinity sowieso, da brauchmer nich weiter rumbabbeln.

Begutachten wird mal den teilweise einstelligen FPS-Zuwachs (LIano) oder gar mal niedrigere frame rates, sicherlich sehr selten aber durchaus vorhanden.
Dann könnte das kommende MCM-Design mit L4-Cache für die iGPU durchaus vielversprechend sein und mit +20% bis 50% über HD4000, wäre man sicher bei LIano.

Selbstverständlich gibt es aber auch bei Intel Folien-Praktikanten.

Das Problem für Intel wäre nicht das die iGPU des Trinity/Richland schnelle sein könnte, sondern die Problem fangen für AMD an, wenn Intel konkurrenzfähig (iGPU-L) wird.

Ich erinnere nochmal daran (ich weiß ihr könnt es nicht mehr hören) das der CPU-Part bei Intel doch um einiges schneller ist, gerade im LV, ULV-Bereich, wird das schon deutlich.
Das Problem für Intel ist jetzt noch die schwache 3D-Leistung (für wen interessant und wo?) und wenn man die einigermaßen an die Konkurrenz anpassen kann, wäre nich so gut für AMD.
Bleibt zu hoffen und da sieht es ja ebenfalls ganz gut aus, dass AMD in Hinblick auf die vermeintlich schneller iGPU auch in Sachen CPU-Performance zulegen kann, das wäre toll - sprach der Troll.

Und wo macht Intel, trotz deutlich schwächeren iGPUs seit 2011 Sales to Record Levels? Da wo es eigentlich unverständlich ist, im Mobilemarkt.
Und zudem mit Server-Microprocessoren, wo es AMD richtig weh tut (mir derzeit um die 6,irgendwas& Markanteil) und die blaue Lösung, als überlegen erscheint.
 
Zuletzt bearbeitet:
Zwen schrieb:
Das Problem für Intel wäre nicht das die iGPU des Trinity/Richland schnelle sein könnte, sondern die Problem fangen für AMD an, wenn Intel konkurrenzfähig (iGPU-L) wird.
Das ist kein Problem, weil ja momentan eh schon jeder AMDs Grafikleistung schlecht redet (Sowas wie: Damit kann man eh Skyrim nicht auf High zocken, also reicht auch eine HD 3000).
Das Problem für AMD ist der Müll der ständig überall verbreitet wird, nicht die Produkte die sie liefern. AMD hat jetzt eine super integrierte Grafik und Intel muss mit der nächsten Generation erstmal gleichziehen. Ivy Bridge (darum geht´s hier übrigens, nicht um Haswell) schafft das jedenfalls weder soft-(da schon gar nicht) noch hardwaremäßig.

Aber ist schon richtig, ich würde jetzt schonmal drüber reden, wie schlecht AMD nächstes Jahr dastehen könnte, dann müssen wir uns nicht mit dem Jetzt-Zustand der Grafikleistung beschäftigen, das geht nämlich zum Nachteil von Intel aus und zwar dicke.
 
Du zitierst mich aus dem Trinity nimmt fahrt auf Spekulations-Thread und packst das hier rein? Okay.

Ja natürlich. Oder sollen wir hier über Amerikas Raumfahrtprogramm und im Boing-Forum über Netzteile diskutieren?

Dann aber bitte vollständig zitieren, und da fehlt ja auch die Vorgeschichte

Für die Vorgeschichte gibts den Link zum Original und das Zitat schien mir für sich aussagekräftig genug. Sorry wenn das zu sehr verkürzt war.

Das Problem für Intel wäre nicht das die iGPU des Trinity/Richland schnelle sein könnte, sondern die Problem fange für AMD dann, wenn Intel mal konkurrenzfähig wird.

Wie man unschwer aus meinem Kommentar ersehen kann sehe ich da nicht wirklich viel Gefahr. Intel hat sich bisher durchgehend bei jeder Grafikarchitektur (erinnert sich noch jemand an den revolutionären Einstieg in den Markt für Grafikkarten?) bis auf die Knochen blamiert. Ok, HD4000 schafft es wenigstens einen stehenden Desktop darzustellen ohne sich zu übernehmen und bringt sogar genug Leistung für Solitaire - Bravo Intel, wirklich toll gemacht (hätschel). Aber damit hat sichs dann auch schon, die blauen Schlümpfe haben schlicht keinen Dunst von Grafik und keine Perspektive was sie über die Erhöhung der Shaderzahl hinaus mit dem Teil anfangen sollen.

Nebenbei: Gibt es schon eine aktuellere Quelle für das Gerücht das Ram in Haswell integriert wird und eine Aussage ob es embedded oder stacked Ram wird?

Ich erinnere Nochmal daran (ich weiß ihr könnt es nicht mehr hören) das der CPU-Part bei Intel doch um einiges schneller ist, gerade im LV, ULV-Bereich.

Aber waren wir uns nicht gerade einig geworden das dem Kunden kaum bis gar nicht auffällt ob er extraordinär-kill-o-Zapp-Rechenleistung statt unglaublich-extraordinär-kill-o-Zapp-Rechenleistung in der CPU hat?

Das Problem für Intel ist jetzt die 3D-Leistung und wenn man die einigermaßen an die Konkurrenz anpassen kann... mhhh.
Bleibt zu hoffen, dass AMD in Hinblick auf die vermeintlich schneller iGPU auch in Sachen CPU-Performance zulegen kann.

Ich weiß zwar nicht was sich durch den Blick auf die tatsächlich schnellere iGPU an der Hoffnung auf Zugewinn an CPU-Performance ändern sollte - aber abgesehen davon stimme ich Dir natürlich gerne zu.
 
Zurück
Oben Unten