- Prohardver app (nem hivatalos)
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Milyen okostelefont vegyek?
- A HMD visszalép az USA piacáról
- Xiaomi 13 - felnőni nehéz
- Légies iPhone halvány színei
- Google Pixel 9 Pro XL - hét szűk esztendő
- 8300 mAh, maradhat?
- Sony WF-C710N - átlátok rajta
- Redmi Note 13 Pro 5G - nem százas, kétszázas!
Új hozzászólás Aktív témák
-
P.H.
senior tag
A másik kérdés, ami bennem felmerült, hogy az rendben van, hogy az AMD GCN-es dGPU-k támogatják majd az x86 virtuális memóriát a CPU pointereken keresztül, de az NV-nek van-e erre licence? Ez bizonytalansági tényező, ami esetlegesen probléma lehet a mixelésnél.
Ezt megoldották az NV helyett az IOMMU-val (és gondolom, a VT-vel). Bár gyakorlati alkalmazását a virtualizáción kívül még nem láttam, de ez csak egy az IOMMU által nyújtott szolgáltatások közül. A chipset megfelelő részeire ültetett TLB-k tartalma a futó processekének megfelelő, és lehetőséget ad arra, hogy - az eddig a GART által biztosított kernelmemória-hozzáférésen kívül - a device a megfelelő process teljes user-space memóriájához is hozzáférjen, közvetlenül, védetten, azzal a feltétellel, hogy HDD-ről való belapozást nem tud kiváltani.
The I/O Memory Management Unit (IOMMU) is a chipset function that translates addresses used in DMA transactions and protects memory from illegal access by I/O devices.
The IOMMU can be used to:
• Replace the existing GART mechanism.
• Remap addresses above 4GB for devices that do not support 64-bit addressing.
• Allow a guest OS running under a VMM to have direct control of a device.
• Provide fine-grain control of device access to system memory.
• Enable a device direct access to user space I/O.2.2.1 Replacing the GART
The GART is a system facility that performs physical-to-physical translation of memory addresses within a graphics aperture. The GART was defined to allow complex graphical objects, such as texture maps, to appear to a graphics co-processor as if they were located in contiguous pages of memory, even though they are actually scattered across randomly allocated pages by most operating systems. The GART translates all accesses to the graphics aperture, including loads and stores executed by the host CPU as well as memory reads and writes performed by I/O devices. Only accesses whose system physical addresses are within the GART aperture are translated; however, the results of the translation can be any system physical address.Unlike the GART, the IOMMU translates only memory accesses by I/O devices. However, with appropriate programming, a host OS can use the IOMMU as a functional equivalent of the GART. First, the host OS must set up its own page tables to perform translations of host CPU accesses formerly translated by the GART. Then, to set up the same translations for I/O device-initiated accesses, the host OS must:
• Construct I/O page tables that specify the desired translations.
• Make an entry in the device table pointing to the newly constructed I/O page tables.
• Notify the IOMMU of the newly updated device table entry if NPcache=1.
At this point, all accesses by both the host CPU and the graphics device are mapped to the same pages as they would have been by the GART.2.2.4 User Mode Device Accesses
The IOMMU plays a crucial role in allowing arbitrary I/O devices to be safely controlled by user-level processes, since I/O devices whose memory accesses are translated by the IOMMU can only access pages that are explicitly mapped by the associated I/O page tables. The I/O devices' access can therefore be limited to only those pages to which the user processes legitimately have access.Setting up the IOMMU for user-level I/O to an I/O device may be set up similarly to GART emulation with two differences: first, the mappable address range is the entire range of I/O device-generatable addresses, and secondly the operating system is not necessarily required to make exactly equivalent mappings in the CPU page tables (although most likely it will).
Even with the help of the IOMMU, enabling user level I/O device access involves many design considerations. Protecting and remapping DMA is one part of the problem; the other part is interrupt management, for which the IOMMU provides help.
As was the case with GART emulation, system software must assess the need to lock in memory all pages that might ever be accessed by an I/O device controlled by a user-level process.
-
P.H.
senior tag
Közben láttam, meg is jelent egy témábavágó cikk.
Úgy tűnik, két dologban nem fogunk egyetérteni: sem abban, hogy egységes felület kialakítását főleg emberi hibák akadályozzák, sem abban, hogy ha valami ellen érveket hoznak fel, akkor jó válasz rá - eltekintve a szokásosan közrejátszó martketingtól -, hogy valóban, de a kritizáló sem tud más területen jobbat felmutatni. Szerencsére az fel sem merül, hogy az ActiveX hiányosságait hardveren vagy driveresen javítsák
, a WebGL-lel felhozott általános GPU-problémákra pedig hardveres sémák már léteznek, csak alkalmazni kell őket előbb-utóbb.A védelem IGP-szinten közel triviálisan megoldható azzal, hogy a lapozást bevezetik az IGP-re is, ezt az akadályt jól vették a single->multi core áttéréskor is, az IGP is csak egy x+1. ágens a rendszerben. Amúgy sem nézi sokáig jó szemmel a világ, hogy a CPU alatti hardver-eszközök virtuálisból a CPU által lefordított kész fizikai címekkel játszadozzanak, ahogy ez most a GPU-k esetében is történik; nem véletlen - noha más, a virtualizáció az oka -, hogy az IOMMU és VT-d megoldások terjedőben vannak. De ez nem is nagy probláma, szinte minden következő generációs APU-nál szóba került már a virtuális címterek megfelelő kezelése.
A multitasking ill. a DoS-szerű nevek pedig - a WebGL-től elszakadva, általánosan is - egyszerű dolgot takarnak: bármikor "túlterhelem" kisebb-nagyobb mértékben a GPU-mat akár most is, jól megírt, jószándékú programokkal. Egy gyors példa: egyszer elindítottam a folding@home-ot, a háttérban szépen futott; hogy megnézzem, milyen sebességgel, rákattintottam a Status-ra, ami elvileg egy kis 3D-animált ablakban mutatja, hogy hol jár éppen a számítás. Elvileg, mert innentől a VGA-m úgy döntött, hogy vannak fontosabb dolgai is az életben, mint a képernyőn levő képet kezelni és frissíteni, onnantól több, 30 perc volt a Ctrl+Alt+Del - Task Manager - Processes fül (ami folyamatosan frissül ráadásul) - End Process Tree utáni OK-ig; felületes szemmel lefagyott a gép, mivel kb. 5 perc volt az első reakció (Windows 7 alatt addigra rég elszállt volna kékhalállal). Mindezt egyetlen program okozta, ami nem volt felkészülve a relatíve gyenge GPU-ra. Ez extrém példa, de azt nem biztos, hogy jó szemmel fogják nézni a felhasználók, ha pl. egy GPU-gyorsított hosszabb videokonvertálást karba tett kézzel kell végigülniük, mint a régi szép DOS-os időkben, mert még böngészni sem nagyon lehet mellette, lévén az is GPU-gyorsított. Erre már nem olyan egyszerű a megoldás, de a megszokott felhasználói élmény ki fogja kényszeríteni.
Mindkét probléma megoldása visszavesz az általános gyorsaságból, de ez egy-két generáció alatt utolérheti magát. Ma sem emlegeti már senki, hogy mennyivel gyorsabbak lennének a játékok, ha egy egyfeladatos, lapozás nélküli OS-sel, flat címzéssel futnának.
Ha ezeket megoldják IGP-ben, következő lépésben vagy akár más ugyanabban bizonyára a saját házon belüli diszkrét kártyákkal való együttműködés is megoldottnak tekinthető.Consumer OS-nek pedig tekinthető a Windows is, pont arról beszélünk, hogy a Microsoft-nak mi az érdeke itt. Gyakran hangoztatod, hogy az NV nagyon készül a Windows 8-ra, nem hiszem, hogy olyan mértékben előtérbe helyezi itt a CUDA-t a C++ AMP-pal szemben, mint ahogy teszi azt az OpenCL esetében.
Viszont a leírt teljes gondolatmeneted valóban helyes, ha úgy nézzük, hogy mire leírtak teljesen kidolgozásra kerülnek, oly mértékben elveszthetik jelentőségüket a diszkrét kártyák a jól fejlett, integrált GPU-kkal rendelkező APU-kkal illetve a platformokkal szemben, hogy nem is lesz érdemes mixelésben gondolkodni.
-
P.H.
senior tag
Tisztában vagyok azzal, hogy a Khronos milyen problémákba ütközik ezen a téren, de ebből nem tenném azt az általánosítást, hogy ennek így kell lennie, és kész.
Az MS már bevitt egy nagy pofont a Khronos által felügyelt WebGL-nek, ami miatt aztán a Khronos-nak magyarázkodnia kellett, mondván, hogy a GPU-k mai fejlettségi szintje és azok driveres támogatása igencsak sok kívánnivalót hagy maga után. Nyilván ezt így, ebben a formában nagy tömegek kezébe adni legalábbis nagy körültekintéssel kell, mivel (ahogy írtam is) és a magyarázatból is kiderül, ma alapvetően multitask-képtelen és biztonságilag elhanyagolt GPU-megoldásokról van szó. Ezt te leütötted azzal, hogy persze, az MS támadja, mert neki csak később lesz ilyen. De nem, az MS sem tud sárból várat építeni, nekik ugyanúgy szükséges az, hogy a gyártók oldják meg ezeket a problémákat, még ha ezek ma tranzisztorpocsékolásnak, felesleges teljesítménycsökkentő feature-öknek is tűnnek, ezt meg kell lépni.
A Khronos lehet gyengekezű, ráhagyhatja a gyártókra az OpenCL-nél is az ilyen-olyan megvalósítást, de nyilván nem ez a széles tömegekhez vezető kulcs.
Ugyanez a helyzet a C++ AMP-nál is: ha nem állít hozzá egy elég erőskezű diktátor megfelelő követelményrendszert, akkor sosem fog hétköznapi, átjártható, normális felületté fejlődni. Ha viszont állít normális feltételeket, akkor semmi akadálya a több gyártó által készített megoldások együttműködésének.
A DirectCompute-t be lehet ágyazni a DirectX-be, ami eléggé izolált, kockázatmentes és a felhasználó által jól kézben tartott módja a GPU-kihasználásnak (az user tudja, mit indít, mikor indít, az milyen adatokkal dolgozik, nem futtat több játékot egyszerre, stb.), de ennél az általános, hétköznapi GPU-gyorsításhoz több kell; mutatja ezt, hogy te sem veszed "komolyan". -
wad
tag
"July – NVIDIA releases updated R280 drivers that incorporate OpenCL v1.1 support previously available to registered developers"
El sem hiszem, röpke egy év kellett hozzá. A kommentek alapján viszont van némi sebesség degradáció a developer és a release drivereknél is. Majd ellenőrzöm, ha éppen nem fagyok
.Szerk: bocs az offtopicért, most látom csak a hírt, amit írtál.
-
#19
bitblueduck
senior tag
Abu85
#14
bitblueduck
senior tag
Az MS azért szokott kommunikálni, meg követelményeket támasztani a gyártók felé. C++ AMP-re valami hasonlót várnék, mint amilyen DX.
Hírhez: Inteltől nem is vártam mást. Minek is kellene támogatni a GPU-kat... jah hogy nekik nincs is a klasszikus értelemben olyan, ami használható lenne
-
P.H.
senior tag
Ezek szerint félreértettél: a gyártóknak nem szükséges egymás termékein tesztelni a saját megoldásukat, viszont a C++ AMP egy szoftverfejlesztő cég ötlete, ami kapcsolatban áll az Intel-el, az AMD-vel, az NV-vel, az ARM-mal és még számos más érintett gyártóval. Az ő ötlete, elvileg az OpenCL mellé, tehát annál valamivel többet vagy valamiben mást kell nyújtania. DirectX vs OpenGL esetben sikerült, így maga mellé állította a játékfejlesztőket.
A saját DirectCompute mellett miért vagy hogyan lehet életképes egy C++ AMP is, ha nem tudna valami pluszt nyújtani?
Pl. azt, hogy akármilyen hardveren és hardverkombináción fut? -
P.H.
senior tag
Feltételeztem, hogy a C++ AMP legalább annyira gyártófüggetlen lesz, mint a DirectX, kiegészülve azzal, hogy akármin (CPU-n, GPU-n, vegyesen) is futtatható, tehát elvileg az összes, gyártók által biztosított felületnek ugyanazt kell tudnia; így viszont megoldható az együttműködésük is.
Ezeket a dolgokat legalább normálisan meg tudta oldani eddig az MS. Ha ezt nem fogja, akkor semmi értelme nem lesz az egésznek.
-
P.H.
senior tag
"Elméletben úgy van kialakítva a felület, hogy nem lehet gond, de a heterogén módon történő futtatásra csak azonos gyártótól származó driverek esetében van garancia. Ugyanígy fog működni a C++ AMP is."
A C++ AMP is? Az MS mint azonos gyártó fogja csinálni a köztes köztesrétegeket a CPU-hoz és a GPU-hoz, vagy hogy kell ezt érteni?
Az is rendben lenne, hogy a gyártók külön készítik a termékeikhez a köztesréteget, de ha ezek együttműködését sem tudja az MS koordinálni, akkor ott valami nem stimmel. A WHQL-mérce ennyire alacsony lesz? -
, a WebGL-lel felhozott általános GPU-problémákra pedig hardveres sémák már léteznek, csak alkalmazni kell őket előbb-utóbb.
Új hozzászólás Aktív témák
Hirdetés
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- Kormányok / autós szimulátorok topikja
- Gránit mosogató
- Milyen légkondit a lakásba?
- Gumi és felni topik
- ASZTALI GÉP / ALKATRÉSZ beárazás
- iRacing.com - a legélethűbb -online- autós szimulátor bajnokság
- Nehéz helyzetben az SMIC, régebbi chipet használ az új Huawei laptop
- PlayStationre is jön az első Gears of War felújítása
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- További aktív témák...
- Intel Core i7-7700K (8M Cache, up to 4.50 GHz) OEM Processor! 27% számlával!
- Eladó ÚJ Intel Core i3 10105F bontatlan dobozos processzor 3 év garancia 27% áfa
- Intel Core i7-8700K 6-Core 3.7GHz LGA1151 (12M Cache, up to 4.70 GHz) Processzor!
- AMD Ryzen 7 5700X3D - BOX - Új, 3 év garancia - Eladó!
- ÚJ, 27% számlás! AMD Ryzen 7 7800X3D (96M Cache, up to 5 GHz) Processzor! BeszámítOK
- Telefon felváráslás!! iPhone 15/iPhone 15 Plus/iPhone 15 Pro/iPhone 15 Pro Max
- Lenovo S10-2 Intel Atom retró csajszis netbook eladó
- Epson Expression 12000 XL Nagyformátumú A3 szkenner
- ÁRGARANCIA!Épített KomPhone i7 14700KF 32/64GB RAM RTX 5070Ti 16GB GAMER PC termékbeszámítással
- Szinte új, minőségi, állítható ritkítóolló
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest