РЕКЛАМА
ИНФОРМАЦИЯ
ПОЛЕЗНЫЕ ССЫЛКИ
OpenGL Workstation Power - Graphics Cards for the Professional User

OpenGL Turbobooster - Diamond's FireGL2

Professional Affair: OpenGL Graphics Cards Compete

Rambler's Top100 Рейтинг@Mail.ru

ВИДЕОКАРТЫ

OpenGL 2.0 - Out To Save Programmable Graphics
Краткое содержание статьи: The danger with pixel shaders and vertex shaders is that there is no standard for programmability of graphics hardware. A schism has formed within DirectX between the competing demands of GPU makers Nvidia and ATI. Noted analyst Jon Peddie gives THG an exclusive first look at a White Paper on how OpenGL 2.0 is trying to bring stability and open standards to programmable graphics and GPUs.

OpenGL 2.0 - Out To Save Programmable Graphics


Редакция THG,  22 февраля 2002
Назад
Вы читаете страницу 7 из 8
1 2 3 4 5 6 7 8
Далее


Functionality, Continued

  • With the ability to get control of memory management if they want it, applications will then be able to adopt and dynamically change a policy. However, the application developers will have to incorporate usage hints for each object and communicate to OpenGL what the application knows about the data usage pattern. This will result in a true, "use once, use many times, write only, bind data asynchronously." It will also provide a unifying mechanism for all objects (e.g., textures, display lists, vertex arrays, images, pixel buffers and shaders). There's no distinction between textures, display list, vertex array memory, etc., and this does not prevent OpenGL implementations from having these object specific pools. Alternatively, an application can still let OpenGL manage memory; it's just another policy.
    OpenGL 2.0 will use a pinned policy where the application gets control so that OpenGL will not move, copy, pack, or delete an object, once data is loaded. The object is pinned down in high performance graphics memory, which lets the application be responsible for storing or deleting objects, or for initiating a packing operation. The new organization is more efficient, as illustrated by the following diagram.

    OpenGL 2.0 Memory Management

  • Asynchronous OpenGL. By adding asynchronous operations to Open GL, OpenGL 2.0 will offer better parallelism and synchronization capabilities. OpenGL traditionally worries about how and where - not when. There has been a long-standing need for better mechanisms that know and control when things happen. Parallelism allows for work to continue, while something is finishing. For example, clear depth buffer while waiting for a swap.
    OpenGL needs a generalized and unified synchronization mechanism that will eliminate the need for each extension to invent its own mechanism. This will: solve short-term problems such as parallel image download; enable more sophisticated use of timing control in the future; enable application to dictate the timing policy; control when things are going to happen; and allow parallel execution of longer OpenGL operations. These long operations can "run in the cracks" with respect to main rendering, which will provide better replacements for flush and finish.
    The net result will be that OpenGL (2.0) will have generalized time control capabilities that will improve parallelism and control of operation timing.
  • GLsync. GLsync is a new OpenGL data type that will provide a unified synchronization mechanism. It can be viewed as a handle. Today, OpenGL provides allocate and de-allocate functions, but no application-managed ID space. In the new version, a thread can wait on a GLsync using OpenGL wait function. The graphics driver can unblock a thread waiting on a GLsync. Glsync can be used very broadly for things like: rendering fences; asynchronous data binding; event notification (e.g., vertical blank); triggered swap completion; and new things not thought of yet ... It will also provide optional integration into underlying operating system synchronization primitive.
    Rendering a fence synchronizes a thread to a stream of rendering commands; it's a superset of the "Finish:" functionality. "Finish" requires stalls of host thread where no new rendering can be issued. OpenGL will be able to use Glsync for such notifications. A thread can issue fence, issue more commands, then wait on GLsync. A "wait" will unblock when the rendering preceding the fence is finished. This allows parallelism that Finish did not.
Назад
Вы читаете страницу 7 из 8
1 2 3 4 5 6 7 8
Далее


СОДЕРЖАНИЕ

Обсуждение в Клубе Экспертов THG Обсуждение в Клубе Экспертов THG


РЕКЛАМА
РЕКОМЕНДУЕМ ПРОЧЕСТЬ!

История мейнфреймов: от Harvard Mark I до System z10 EC
Верите вы или нет, но были времена, когда компьютеры занимали целые комнаты. Сегодня вы работаете за небольшим персональным компьютером, но когда-то о таком можно было только мечтать. Предлагаем окунуться в историю и познакомиться с самыми знаковыми мейнфреймами за последние десятилетия.

Пятнадцать процессоров Intel x86, вошедших в историю
Компания Intel выпустила за годы существования немало процессоров x86, начиная с эпохи расцвета ПК, но не все из них оставили незабываемый след в истории. В нашей первой статье цикла мы рассмотрим пятнадцать наиболее любопытных и памятных процессоров Intel, от 8086 до Core 2 Duo.

ССЫЛКИ
Реклама от YouDo