nVidia Linux Display Driver 331.20 z obsługą interfejsu API EGL oraz NvFBCOpenGL

nVidia Linux Display Driver 331.20 z obsługą interfejsu API EGL oraz NvFBCOpenGL

przez -
6 339
nVidia
nVidia ogłosiła wydanie nVidia Linux Display Driver 331.20 (wersja angielska). Dodano wsparcie dla nVidia OpenGL-based Framebuffer CaptureNvFBCOpenGL. Ta biblioteka odpowiada za wysoką wydajność i niskie opóźnienia interfejsu do przechwytywania obrazu z ekranu, i jego późniejszego ewentualnego kodowania. NvFBC i NvIFR są niestety zamkniętymi API, przez co są dostępne jedynie dla zaufanych partnerów, do użytkowania w aplikacjach zdalnego sterowania.

Dodano nowy atrybut do rozszerzenia NV-CONTROL, który ma być odpowiedzialny za kontrolę jasności podświetlenia – NV_CTRL_BACKLIGHT_BRIGHTNESS. W panelu sterowania nvidia-settings dodano raportowanie użycia układu graficznego. Pojawiła się opcja pokazywania bieżącej prędkości obrotowej wentylatora, na kartach które to wspierają oraz w interfejsie API NV-CONTROL.

Dodano obsługę interfejsu API EGL na 32-bitowych platformach sprzętowych. Obecnie wspierane są: OpenGL ES 1.1, OpenGL ES 2.0 oraz OpenGL ES 3.0, a jedynym obsługiwanym systemem okien jest X11.

Dodano nową opcję: AllowEmptyInitialConfiguration, która pozwala na uruchomienie X serwera w sytuacji, gdy podczas jego uruchamiania nie wykryto podłączonych wyświetlaczy. Opcję można włączyć poprzez komendę: sudo nvidia-xconfig --allow-empty-initial-configuration. Jest ona użyteczna przy niektórych konfiguracjach wyświetlania RandR 1.4, gdy do karty graficznej nie jest podłączony żaden monitor.

Uaktualniono narzędzie nvidia-installer, aby podczas instalacji dodawało biblioteki libvdpau i libvdpau_trace, jeżeli nie zostały one wykryte w systemie. Opcję tą można wyłączyć: --install-vdpau-wrapper oraz --no-install-vdpau-wrapper.

  • o_O

    Wersja 331.17 (beta) jest wyraźnie szybsza od serii 319.x, przynajmniej na niektórych kartach. Zaraz sprawdzę stabilną 331.20.

    • NoNaMe

      Pewnie nie będziesz umiał.

  • Wintel Outside

    "Ta biblioteka odpowiada za wysoką wydajność i niskie opóźnienia interfejsu do przechwytywania obrazu z ekranu, i jego późniejszego ewentualnego kodowania. NvFBC i NvIFR są niestety zamkniętymi API, przez co są dostępne jedynie dla zaufanych partnerów, do użytkowania w aplikacjach zdalnego sterowania."

    To specjalnie przygotowane API dla NSA, by mogli namierzać potencjalnych terrorystów podglądając jak tną w FPS-y ;-)

  • kwahoo

    Podejrzewam, że to może mieć jakiś związek z zapowiedzianym ostatnio przez Mozillę i Amazon ORBX.js

    "The GRID GPU incorporates an important feature that makes it ideal for building cloud-based applications. If you examine the diagram above, you will see that the NVIFR and NVFBC components are connected to the frame buffer and to the NVENC component. When used together (NVIFR + NVENC or NVFBC + NVENC), you can create an H.264 video stream of your application using dedicated, hardware-accelerated video encoding. This stream can be displayed on any client device that has a compatible video codec. A single GPU can support up to eight real-time HD video streams (720p at 30 fps) or up to four real-time FHD video streams (1080p at 30 fps)."
    http://aws.typepad.com/aws/2013/11/build-3d-strea

    • pijaczek

      Raczej z Nvidia GRID jako podstawa do tworzenia konkurencji dla OnLive. Po prostu jeśli chcesz grać na telefonie ze słabymi podzespołami w najbardziej wymagające gry na PC, płacisz abonament i karta graficzna na serwerze pracuje i strumieniuje obraz i dźwięk w jedną stronę, a w drugą to co robi gracz (kontroler podpięty pod telefon/telewizor lub ekranowe przyciski). Żeby być lepsi niż konkurencja i osiągać to czym się chwali na porównaniach ( http://www.nvidia.com/content/cloud-computing/ima… ) trzeba zagwarantować "nisko opóźnieniowe api" i w sterownikach trzeba je obsługiwać. OFC api nie może być publiczne jeśli chce się sprzedawać dużo droższe karty NVIDIA GRID i musi być dostępne tylko dla partnerów.

      Co do partnerów to małą ich część trafiłeś, ale to nie tyle ma związek z Mozillą czy Amazon, a odwrotnie – OTOY ORBX.js (które obie firmy chcą wykorzystać, ale Amazon jeszcze ma wiele innych zastosowań dla GRID w Amazon EC2), ma związek z projektem Nvidia GRID. To co napisałeś to tak jakby poprawki w Nvidia CUDA miały związek z OTOY OctanRenderer, a nie odwrotnie ;p.