Új hozzászólás Aktív témák

• #32 P.H. senior tag Abu85 #31

  Új Válasz 2011-08-17 10:57:04 #32

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  P.H.

  senior tag

  válasz Abu85 #31 üzenetére

  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.

  [ Szerkesztve ]

  Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

• #33 P.H. senior tag Abu85 #31

  Új Válasz 2011-08-17 15:07:30 #33

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  P.H.

  senior tag

  válasz Abu85 #31 üzenetére

  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.

  [link]

  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.

  Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

Új hozzászólás Aktív témák