| Age | Commit message (Collapse) | Author |
|---|
|
Swap buffers is a fairly reasonable time to wait for the hardware for a
while; this keeps us from overrunning the ring.
|
|
|
|
Instead of passing in a fixed struct, the loader now passes in a list
of __DRIextension structs, to advertise the functionality it can provide
to the driver. Each extension is individually versioned and can be
extended or phased out as the interface develops.
|
|
|
|
|
|
Increases OA performance by about 3%.
|
|
|
|
The previous code would reference freed memory on window moves.
|
|
The previous change gave us only two modes, one which looped over the batch
per cliprect (3d drawing) and one that didn't (state updeast).
However, we really want 4:
- Batch doesn't care about cliprects (state updates)
- Batch needs DRAWING_RECTANGLE looping per cliprect (3d drawing)
- Batch needs to be executed just once (region fills, copies, etc.)
- Batch already includes cliprect handling, and must be flushed by unlock time
(copybuffers, clears).
All callers should now be fixed to use one of these states for any batchbuffer
emits. Thanks to Keith Whitwell for pointing out the failure.
|
|
In particular, batch buffers are no longer flushed when switching from
CLIPRECTS to NO_CLIPRECTS or vice versa, and 965 just uses DRM cliprect
handling for primitives instead of trying to sneak in its own to avoid the
DRM stuff. The disadvantage is that we will re-execute state updates per
cliprect, but the advantage is that we will be able to accumulate larger
batch buffers, which were proving to be a major overhead.
|
|
Each array element is now a BUFFER_x token rather than a BUFFER_BIT_x bitmask.
The number of active color buffers is specified by _NumColorDrawBuffers.
This builds on the previous DrawBuffer changes and will help with drivers
implementing GL_ARB_draw_buffers.
|
|
These fields are no longer indexed by shader output. Now, we just have
a simple array of renderbuffer pointers.
If the shader writes to gl_FragData[i], send those colors to the N
_ColorDrawBuffers. Otherwise, replicate the single gl_FragColor (or
the fixed-function color) to the N _ColorDrawBuffers.
A few more changes and simplifications can follow from this...
|
|
To do so, merge the remainnig necessary code from the buffers, blit, span, and
screen code to shared, and replace it with those.
|
|
The 965 driver relies on flag checking instead of these hooks, and will be
using this code soon.
|
|
|
|
Otherwise, we may violate cliprect asssertions on clearing the buffers, which
isn't affected by the fallback.
|
|
The diffuse color format is always ARGB32, regardless of the destination
surface format.
|
|
|
|
|
|
Don't dereference NULL renderbuffer pointer, and make sure the software
fallback sticks.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=13694 .
|
|
The lock coverage and checks for cliprects were unneeded since the batchbuffer
will have INTEL_BATCH_CLIPRECTS anyway. It appeared to be a leftover from
intelClearWithBlit.
This makes the locking requirements of i915 meta_draw_quad match i965
meta_draw_quad.
|
|
This was replaced in previous releases of xserver/dri/libGL by reporting the
damage to the frontbuffer so that the server and driver could handle it
appropriately.
|
|
|
