Device vendor on se, kenen OpenCL-ajoympäristöä(eli siis käytännössä OpenCL-kääntäjää) käytetään. Tällä ei ole mitään tekemistä cpuid:n kanssa.
Ajamalla windowsia virtuaali ympäristössä esim linuksissa xenin alla ja feikkaamalla CPUID kuten olen nyt koittanut kertoa jo useamman viestin ajan.
Edelleen olen jo kaksi kertaa osoittanut että mitään cpuid:tä ei ole feikattu koska se näkyy aivan oikein tuossa CL_DEVICE_NAME:ssa.
Saat luennoida ihan vaikka valkoisessa talossa. Jos et halua faktoja nähdä niin se ei ole minun ongelma. Testiohjelmassa EI voi valita kenen tekemää OpenCL rajapintaa käytetään ja ohjelma on käännetty intelin kääntäjällä. Ainoa keino vaihtaa sitä kenen CL:llä ajellaan on valehdella CPUID ja family joka käy selväksi jos olisit viitsinyt lukea sen linkin jonka laitoin jossa myös kerrotaan hyvin selväksi MIKSI ohjelmat käyttäytyvät eri tavalla kun käytetään Intelin kääntäjää.
Asennetaan se koneelle.
Tiedän faktat aika paljon sinua paremmin tästä.
OpenCL-ohjelmat kutsuvat aina alussa ohjelman metodia, jolla haetaan koneessa olevat OpenCL-ajoympäristöt, ja ohjelma voi näistä valita haluamansa.
Slllä, millä host-ohjelma on käännetty ei ole mitään väliä.
clGetPlatformIDs
Kyseinen linkkisi ei liity millään tavalla OpenCL:ään josta olet pihalla kuin lumiukko.
Tuolla nimenomaan on ne benchmark-tulokset molemmilla.
Juuri se tuolla on tehty. Ajettu Ryzenillä, käyttäen sekä AMDn omaa, että intelin OpenCL-implementaatiota. Ei tuolla ole kukaan spooffannut yhtään mitään.
Ja ihan huvikseen vain ilmoittaa "Compute Performance of Intel® Ryzen 7 1800X Eight-Core Processor"
Lue ne laitteen tiedot sieltä, ihan AMD Ryzen siellä lukee.
Detaileissa mainitaan:
Tossa sivulla mainittiin että SR oli nopeampi sillonkun oikeasti alettii kiristämään asetuksia, autolla DR oli nopeampi.
Nojuu. Ei sitä älypuhelimella päässy mihinkään. Muutenkin työpäivä, ei ollut aikaa. Geardown offilla sain 3dmark sky divessa noin 1% parannuksen yhdistelmätuloksessa. Noin 33800 pistettä Nano näytönohjaimen kanssa. Ennen oli noin 33500 pistettä.
@Kaotik Tämän voisi kai ihan etusivullakin julkaista, kun olet aiemminkin uutisoinut näistä jutuista
Eiköhän se sinne saada@Kaotik Tämän voisi kai ihan etusivullakin julkaista, kun olet aiemminkin uutisoinut näistä jutuista
Täytyy toivoa että mobiili Ryzen lyö sitten vielä lisää löylyä. Olisi suotavaa että AMD pääsee hieman keräilemään itseään ja saadaan kunnon kilpailu pystyyn.
Käsittääkseni 1.0.0.7 on tekeillä.
Jospa tuossa olisi saatu korjattu Linuxissa havaitut ongelmat jos on mikrokoodilla edes korjattavissa.
Netistä sai kuvan, että joku versio tuosta olisi jo emovalmistajien biostiimeillä käsittelyssä. Enkä suoraan sanoen usko, että tuokaan versio on viimeinen. Eiköhän niitä tule vielä ainakin muutama, että saavat hiottua biosit viimeisen päälle trimmiin. Kannattaa muistaa, että ei se DDR4 tuen toimivuus Intelin puolellakaan tullut kuin taikasauvasta heilauttamalla.
Se olisi jo järjenvastaista AMD:ltä jättää mikrokoodi päivittämättä. Ryzen on monelta kantilta katsottuna kultakaivos, joten sille varmasti allokoidaan paljon miestyötunteja. AGESA-päivityksiä on varmasti tulossa useita, mutta niiden aikataulusta ei ole tietoa.
..mutta Linuksen Cinebench oli vähemmän (-8%) - ja sillä ainakin semmoinen oli.
Joutuivat vaihtamaan muistit koneeseen. Mun linkkaamassa oli 3200mhz muistit käytössä.
Se voisi kyllä selittää eron.
Cinebenchillä alkaa tulla aika vaihtelevia tuloksia isoilla coremäärillä, en tiijä että vaikuttaako viel tuolla coremäärällä mut täs näkee hyvin mite tulee 20% heittoja.
Kuulema ainakin ekat Threadripperit olisivat B1. Tosin niistä kiersi juttua, että AMD olisi valinnut niihin parhaat 5% piireistä.
Kyllä se on kaikilla ryseneillä, Threadripperistä ei tietoa eikä EPYC:stä. Ja Threadripper on edelleen B1, ainoastaan EPYC on B2. AMD on tietoinen tuosta ongelmasta ja AMD:n forumilla jotkuu on saanu AMD:ltä suoraan RMA:n kautta toimivan CPU:n jotka on edelleen B1. Joku valitteli että RMA:sta tullut olisi seqfaultannu kanssa.
Mitä Phoronixin keskustelua asiasta luin, niin kaatuu myös winukan WSL:llä (tarkoitan sitä windowsin linux konsolia/mikä lie). Mutta BSD:llä olisi kerneliin tehty joku patchi jolla ongelma vähenee.
Tuo ei käsittääkseni ole mahdollista, ellei AMD:lle lähetetty prossu ole ollut suoraan viallinen. Nykyään taitaa vain olla aika hankalaa saada ostettua liikkeestä viallista prosessoria. Prossussa voi olla suunnitteluvirhe, jolloin kaikki valmistuneet prossut kärsivät samasta ongelmasta, mutta se että vakiona toinen prossu toimii ja toinen ei, kun käytetään juuri samoja komponentteja, niin tälläistä ilmiötä ei taida nykypäivänä tulla vastaan.
Windowsissa ongelmaa ei ole huomattu koska windowsilla on melko vähän henkilöitä jotka oikeasti raskasta kuormaa ajaisi. Tuo ongelma alkoi esiintyä nimenomaan Gentoo käyttäjien keskuudessa koska Gentoo on distro jossa käyttäjä käytännössä kääntää kaikki ohjelmat itse eikä asentele valmiiksi käännettyjä paketteja kuten lähes kaikissa muissa distroissa tehdään. BSD taitaa olla kanssa sellainen että paketit käännetään sorsista itse.
Miksei olisi? Jokainen prosessori on yksilö. Jos ne kaikki olisi samanlaisia, niin silloinhan ne kaikki myös kellottuisi täysin samoin.
Eihän saman kernelin toimiminen prosessorilla X tarkoita 100% toimivuutta prosessorilla Y. Ensin pitäisi oikeasti sulkea softabugi pois ja sen jälkeen voitaisiin todeta vian olevan raudassa. Joka tapauksessa toivottavasti ongelman saa ratkaistua softapohjaisesti.
Kiinnostaisi tietää vähän tarkemmin mikä on tällainen "oikeasti raskas kuorma". Siinä ei ole myöskään mitään kovin ihmeellistä että sama ohjelma toimii tietyllä prosessorilla muttei toimi jollakin toisella.Windowsissa ongelmaa ei ole huomattu koska windowsilla on melko vähän henkilöitä jotka oikeasti raskasta kuormaa ajaisi. Tuo ongelma alkoi esiintyä nimenomaan Gentoo käyttäjien keskuudessa koska Gentoo on distro jossa käyttäjä käytännössä kääntää kaikki ohjelmat itse eikä asentele valmiiksi käännettyjä paketteja kuten lähes kaikissa muissa distroissa tehdään. BSD taitaa olla kanssa sellainen että paketit käännetään sorsista itse.
Ongelma on xBSD:llä ja linuksilla ja noilla ei niin kovin paljon yhteistä ole niin en oikein jaksa uskoa että olisi Linux/BSD ongelma koska noi rysen testit Intelin prossuilla ja muilla AMD prossuilla toimii ongelmitta.
Kääntäminen on todella raskasta kuormaa, olisi kiva nähtä mitä tämänkin palstan kellottelijoiden "vakaille" koneille kävisi kun asennettaisiin Gentoo ja laitettaisiin kone oikeisiin töihin.
Tietenkin saa. Kernel spacessa hölmöillessä saa käyttiksen kaatumaan varmasti, bugiset ajurit lienee tuttuja kaikille pidempään atk:ta naputelleille.
JOkainen prossu testataan ennen myyntiä. Ja testin pitäisi olla riittävät kattava, ettei vakiona ajettaessa pitäisi olla ongelmaa. Jos vakiona esiintyy myyntiin päässeiden prossujen toiminnassa eroja, niin AMD testaus ei ole riittävää, tai sen toteutuksessa on jotain mätää.
