Концептуальная модель графического приложения, использующего функции OpenGL
жүктеу/скачать 84.5 Kb.
|
- Бұл бет үшін навигация:
- Графический конвейер
- 2. Обеспечение производительности OpenGL программ
- Узкие места на уровне стадии приложений.
- Узкие места геометрических преобразований.
- Optimizing Lighting Performance
- Minimizing Cache Misses.
- Minimizing State Changes.
- .2 Decomposition and Tessellation
OpenGL С точки зрения архитектуры графическая система OpenGL является конвейером, состоящим из нескольких последовательных этапов обработки графических данных. Команды OpenGL всегда обрабатываются в том порядке, в котором они поступают, хотя могут происходить задержки перед тем, как проявится эффект от их выполнения. В большинстве случаев OpenGL предоставляет непосредственный интерфейс, т.е. определение объекта вызывает его визуализацию в буфере кадра. С точки зрения разработчиков, OpenGL – это набор команд, которые управляют использованием графической аппаратуры. Если аппаратура состоит только из адресуемого буфера кадра, тогда OpenGL должен быть реализован полностью с использованием ресурсов центрального процессора. Обычно графическая аппаратура предоставляет различные уровни ускорения: от аппаратной реализации вывода линий и многоугольников до изощренных графических процессоров с поддержкой различных операций над геометрическими данными. 
Рис. 1. Функционирование конвейера OpenGL Отмети также, что OpenGL можно рассматривать также как конечный автомат, состояние которого определяется множеством значений специальных переменных и значениями текущей нормали, цвета, координат текстуры и других атрибутов и признаков. Вся эта информация может быть использована при поступлении в графическую систему координат вершины для построения фигуры, в которую она входит. Смена состояний происходит с помощью команд, которые оформляются как вызовы функций. Графический конвейерВ самом общем виде можно рассматривать 3-х фазный конвейер OpenGL, каждая фаза которого, в зависимости от реализации, может выполняться CPU или графической платой (accelerator card). В рамках такой концептуальной модели (лекция 1) удобно рассмотреть временные (и другие ресурсные) затраты программы. Итак, рассматриваем следующие стадии (фазы) конвейера:
Структура затрат на выполнение зависит от структуры приложения. Например, для программы, рисующей небольшое число полигонов, геометрические преобразования займут заведомо меньше времени чем растеризация большого числа пикселей. Соответственно, главным фактором производительности в этом случае является уменьшение числа используемых пикселей, или упрощение текстур. 2. Обеспечение производительности OpenGL программПовысить производительность( сократить время выполнения) графических программ можно как за счет более эффективного использования оборудования (hardware), так и программ. Обеспечивать эффективность работы программ можно за счет оптимизации кода и выполнения определенных правил их организации, которые относятся к обеспечению определенного компромисса между точностью и производительностью. Эти правила, разумеется, должны иметь учитывать характеристики используемого оборудование (платформы). ниже мы рассмотрим основные правила оптимизации.
Под “узким местом” (bottleneck) производительности приложения будем понимать элементы (участки) программ и оборудования, структурные и функциональные характеристики которых препятствуют достижению высокой производительности. Например, видеокарта с малой памятью является узким местом для графического приложения на высокопроизводительном (по остальным характеристикам) платформе. Узкие места можно определить, измеряя времена выполнения программ или их участков. Если оказывается, что изменение в элементах, подозреваемых как bottleneck приводит к существенному сокращению времени выполнения программы, то мы действительно нашли узкое место. и способ его устранения. Итак, чтобы решить задачу повышения производительности, следует - определить элементы (компоненты) программ и/или оборудования, которые могут быть причиной низкой производительности, -выбрать программы или наборы данных, на которых может проявиться недостаток производительности, - произвести измерения времени выполнения
Причиной Geometry bottlenecks может быть пропускная способность шины между CPU и графической картой, что можно проверить устранив вызовы glColor3fv() или glNormal3fv() . Основные факторы, влияющие на производительность приведены в таблице 1.
Известно, что до 90% времени выполнения графических приложений приходится на сравнительно небольшую часть кода (не более 10% ) кода. Большинство графических акселераторов настроены на работу с конвейером, где одна фаза (сегмент) выполняетгеометрические преобразования и вычисление освещенности, в то время как другая прорисовывает пиксели в буфер кадров (frame buffer). Поскольку оба сегмента конвейера выполняются одновременно, в каждый момент один из сегментов-“узкое место”, и его оптимизация наилучшим образом повлияет на производительность. Так как разные части программ воздействуют на различные фазы конвейера, важно понять, какие из элементов образуют “ узкие мета” Если графическая задача решается только программными средствами, нет смысла увеличивать рабочую нагрузку для одной из фаз, если другая использует сущестенно больше процессорного времени. Это может лишь снизить производительность. Чтобы повысить производительность на фазе геометрических преобразований, следует по возможности отключать свойства, требующие для своей реализации значительных ресурсов, но без которые, приданных к требованиях к качеству сцены, можно обойтись. Например, использования моделирования тумана (параметр GL_FOG в glEnable) замедляет скорость геометриеских преобразований для полигонов. Поэтому, если, например, используемая плотность тумана близка к нулю, это свойство можно попробовать отключить glDisableGL_FOG (GL_FOG). Основные рекомендации по оптимальной, с точки зрения производительности, организации программ, использующих библиотеки OpenGL, можно найти в материале tutorial.doc, отправленный всем Вам в начале семестра. Ниже приводится дополнительный список рекомендаций по управлению производительностью.
Optimizing Transformations
Optimizing Lighting PerformanceOpenGL offers a large selection of lighting features. The penalties some features carry may vary depending on the hardware you're running on. Be prepared to experiment with the lighting configuration. As a general rule, use the simplest possible lighting model: a single infinite light with an infinite viewer. For some local effects, try replacing local lights with infinite lights and a local viewer. Keep in mind, however, that not all rules listed here increase performance for all architectures. Use the following settings for peak performance lighting:
In addition, follow these guidelines to achieve peak lighting performance:
There may be a sharp drop in lighting performance when adding lights.
Local lights are noticeably more expensive than infinite lights.
If local lights must be used, a positional light is less expensive than a spot light.
Changing material parameters can be expensive. If you need to change the material parameters many times per frame, consider rearranging the scene to minimize material changes. Also consider using glColorMaterial() if you need to change some material parameters often, rather than using glMaterial() to change parameters explicitly. Changing material parameters inside a glBegin()/glEnd() sequence can be more expensive than changing them outside. The following code fragment illustrates how to change ambient and diffuse material parameters at every polygon or at every vertex: glColorMaterial(GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE); glEnable(GL_COLOR_MATERIAL); /* Draw triangles: */ glBegin(GL_TRIANGLES); /* Set ambient and diffuse material parameters: */ glColor4f(red, green, blue, alpha); glVertex3fv(...);glVertex3fv(...);glVertex3fv(...); glColor4f(red, green, blue, alpha); glVertex3fv(...);glVertex3fv(...);glVertex3fv(...); ...
glEnd();
Local viewing: Setting GL_LIGHT_MODEL_LOCAL_VIEWER to GL_TRUE with glLightModel(), while using infinite lights only, reduces performance by a small amount. However, each additional local light noticeably degrades the transform rate.
Two-sided lighting illuminates both sides of a polygon. This is much faster than the alternative of drawing polygons twice. However, using two-sided lighting can be significantly slower than one-sided lighting for a single rendering of an object.
If possible, provide unit-length normals and don't call glScale\*() to avoid the overhead of GL_NORMALIZE. On some OpenGL implementations it may be faster to simply rescale the normal, instead of renormalizing it, when the modelview matrix contains a uniform scale matrix. The normal rescaling functionality in OpenGL 1.2, or the EXT_rescale_normal extension for older OpenGL versions, can be used to improve the performance of this case. If it is supported, you can enable GL_RESCALE_NORMAL_EXT and the normal will be rescaled making re- normalization unnecessary.
Some portions of the lighting calculation may be approximated with a table, and changing the GL_SHININESS value may force those tables to be regenerated. Minimizing Cache Misses.Most CPUs have first-level instruction and data caches on chip and many have second-level caches that are bigger but somewhat slower. Memory accesses are much faster if the data is already loaded into the first-level cache. When your program accesses data that isn't in one of the caches, a cache miss occurs. This causes a block of consecutively addressed words, including the data that your program just accessed, to be loaded into the cache. Since cache misses are costly, you should try to minimize them, using these tips:
Some framebuffers have cache-like behaviors as well. It is a good idea to group geometry so that the drawing is done to one part of the screen at a time. Using triangle strips and polylines tends to do this while simultaneously offering other performance advantages as well. Minimizing State Changes.Your program will almost always benefit if you reduce the number of state changes. A good way to do this is to rearrange your scene data according to what state is set and render primitives with the same state settings together. Mode changes should be ordered so that the most expensive state changes occur least often. Typically it is expensive to change texture binding, material parameters, fog parameters, texture filter modes, and the lighting model. However, some experimentation will be required to determine which state settings are most expensive on your target systems. For example, on systems that accelerate rasterization, it may not be that expensive to change rasterization controls such as the depth test function and whether or not depth testing is enabled. However, if you are running on a system with software rasterization, this may cause cached graphics state, such as function pointers or automatically generated code, to be flushed and regenerated. Your target OpenGL implementation may not optimize state changes that are redundant, so it's also important for your application to avoid setting the same state values twice, such as enabling lighting when it is already enabled. .2 Decomposition and TessellationTessellation refers to the process of decomposing a complex surface such as a sphere into simpler primitives such as triangles or quadrilaterals. Most OpenGL implementations are tuned to process triangle strips and triangle fans efficiently. Triangles are desirable because they are planar, easy to rasterize, and can always be interpolated unambiguously. When an implementation is optimized for processing triangles, more complex primitives such as quad strips, quads, and polygons are decomposed into triangles early in the pipeline. If the underlying implementation is performing this decomposition, there is a performance benefit in performing this decomposition a priori, either when the database is created or at application initialization time, rather than each time the primitive is issued. A second advantage of performing this decomposition under the control of the application is that the decomposition can be done consistently and independently of the OpenGL implementation. Since OpenGL doesn't specify its decomposition algorithm, different implementations may decompose a given quadrilateral along different diagonals. This can result in an image that is shaded differently and has different silhouette edges when drawn on two different OpenGL implementations. Quadrilaterals may be decomposed by finding the diagonal that creates two triangles with the greatest difference in orientation. A good way to find this diagonal is to compute the angles between the normals at opposing vertices, compute the dot product, then choose the pair with the largest angle (smallest dot product) as shown in Figure 2. The normals for a vertex can be computed by taking the cross products of the the two vectors with origins at that vertex. An alternative decomposition method is to split the quadrilateral into triangles that are closest to equal in size. Tessellation of simple surfaces such as spheres and cylinders is not difficult. Most implementations of the GLU library use a simple latitude-longitude tessellation for a sphere. While the algorithm is simple to implement, it has the disadvantage that the triangles produced from the tessellation have widely varying sizes. These widely varying sizes can cause noticeable artifacts, particularly if the object is lit and rotating. A better algorithm generates triangles with sizes that are more consistent. Octahedral and icosahedral tessellations work well and are not very difficult to implement. An octahedral tessellation approximates a sphere with an octahedron whose vertices are all on the unit sphere. Since the faces of the octahedron are triangles they can easily be split into four triangles, as shown in Figure 3. Each triangle is split by creating a new vertex in the middle of each edge and adding three new edges. These vertices are scaled onto the unit sphere by dividing them by their distance from the origin (normalizing them). This process can be repeated as desired, recursively dividing all of the triangles generated in each iteration. The same algorithm can be applied using an icosahedron as the base object, recursively dividing all 20 sides. In both cases the algorithms can be coded so that triangle strips are generated instead of independent triangles, maximizing rendering performance. It is not necessary to split the triangle edges in half, since tessellating the triangle by other amounts, such as by thirds, or even any arbitrary number, may produce a more desirable final uniform triangle size. жүктеу/скачать 84.5 Kb. Достарыңызбен бөлісу:
| ||||||||||||||||||
