| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Windows opengl32.dll calls glFinish prior to every swapbuffers, which
makes it pretty hard to get decent performance...
Work around by mapping finish to flush on PIPE_OS_WINDOWS. This is
conformant, though it might confuse poorly-written benchmarks which
attempt to measure a single event rather than figuring out the rate of
continuous processing.
|
| |/
|
|
|
|
|
|
|
|
| |
Indicates whether there's defined image contents, or garbage/don't care.
This is set when we draw into a renderbuffer and cleared when we resize/
reallocate a renderbuffer or do a buffer swap (back buffer becomes undefined).
We use this to determine whether the front color buffer has been drawn to,
and whether to display its contents upon glFlush/Finish(), when the new
st_swapbuffers() function is used.
|
| |
|
|
| |
Already doing this for driver.flush()
|
| |
|
|
|
|
| |
Not sure if this indicates a problem elsewhere, but without this check
trivial/tri-fbo.c segfaults on resize. With the patch, it renders
correctly.
|
| |
|
|
|
|
|
|
|
| |
It is not the state tracker's responsibilty to inject sleeps and
pessimize performance in the hope of avoiding buffer synchronization
issues in buggy drivers.
Calling finish() here will just hide problems that need to be fixed
elsewhere.
|
| |
|
|
|
| |
move it to pipe/internal/p_winsys_screen.h and start converting
the state trackers to the screen usage
|
| |
|
|
|
|
|
|
|
|
|
| |
Quite a few util modules were maintaining a single vertex buffer over multiple
frames, and potentially reusing it in subsequent frames. Unfortunately that
would force us into syncrhonous rendering as the buffer manager would be
forced to wait for the previous rendering to complete prior to allowing the
map.
This resolves that issue, but requires the state tracker to issue a few new
flush() calls at the end of each frame.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This fixes the case where the app calls SwapBuffers then calls glReadPixels
to read the front color buffer. We now keep track of when the front buffer
is a _logically_ copy of the back buffer (after SwapBuffers) and read from
the back color buffer instead of the front.
|
| |
|
|
| |
New, separate is_front_buffer_dirty() function.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
As st_gl_flush() isn't used by st_finish() anymore, it doesn't have to make
sure pipe->flush() always gets called.
|
| |
|
|
|
| |
This is enough for the current purpose of st_finish(), which is to wait for
things to settle down before context teardown.
|
| |
|
|
|
|
| |
Make sure the struct pipe_fence_handle* we point st_flush() to is initialized
to NULL, so winsys->fence_reference() doesn't try to unreference a random
struct pipe_fence_handle* pointer.
|
| |
|
|
|
|
|
| |
The bitmap cache attempts to accumulate a series of glBitmap calls in a
buffer to effectively render a whole bunch of bitmaps at once.
The cache can be disabled, if needed, by setting UseBitmapCache=GL_FALSE.
|
| |
|
|
|
| |
The cell driver still uses an internal CELL_FLUSH_WAIT flag, in the long run
proper fencing should be implemented for it.
|
| | |
|
| | |
|
| |
|
|
| |
This broke the LLVM build because 'private' is a C++ keyword.
|
| |
|
|
|
| |
The state tracker doesn't have to directly call winsys->wait_idle() anymore.
glFlush and glFinish both go through pipe->flush() now.
|
| |
|
|
|
|
| |
The winsys object is now per-screen and shared by multiple contexts.
The regionPool is now part of the i915 winsys layer.
The winsys wait_idle() and flush_frontbuffer() funcs will get more attention...
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
intelCopyBuffer() is now intelDisplayBuffer(): it displays the given surface
in the on-screen window.
Added a pipe_surface parameter to winsys->flush_frontbuffer().
Front buffer rendering/flushing actually works now.
But, we should only allocate the front surface on demand...
|
| | |
|
| |
|
