| Age | Commit message (Collapse) | Author |
|---|
|
(cherry picked from commit df70d3049a396af3601d2a1747770635a74120bb)
|
|
The _Enabled field isn't updated at the point that DrawBuffers is called,
and the Driver.Enable() function does the testing for stencil buffer
presence anyway.
bug #21608 for Radeon
(cherry picked from commit 4c6f82989983eecc0b3b724716cb3bcb675664c5)
|
|
For non-stereo visuals, which is all we support, we treat
GL_FRONT_LEFT as GL_FRONT. However, they are technically different,
and they have different enum values. Test for either one to determine
if we're in front-buffer rendering mode.
This fix was suggested by Pierre Willenbrock.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 2085cf24628be7cd297ab0f9ef5ce02bd5a006e2)
|
|
This interface gives the driver two important features. First, it can
allocate the (fake) front-buffer only when needed. Second, it can
tell the buffer allocator the format of buffers being allocated. This
enables support for back-buffer and depth-buffer with different bits
per pixel.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@redhat.com>
|
|
It is possible for ctx->DrawBuffer to be NULL, so don't fault when
that happens. This change is not being committed to master because it
doesn't appear to be necessary there.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cherry picked from mesa_7_4_branch, commit 49e0c74ddd91900fc4effb6d305d56e0563b456d
|
|
Track two flags: whether or not front-buffer rendering is currently
enabled and whether or not front-buffer rendering has been enabled
since the last glFlush. If the second flag is set, the front-buffer
is flushed via a loader call back. If the first flag is cleared, the
second flag is cleared at this time.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@redhat.com>
|
|
|
|
|
|
This saves an inadvertent round-trip to the X Server on DrawBuffers, which was
hurting some metaops.
|
|
|
|
intel_swapbuffers.c
|
|
Fix the last merge fix, had the blocks ordered incorrectly.
|
|
Bah, applied the patches in the wrong order, not Owain's fault...
|
|
On Mobile chipsets, we often enable PipeB instead of PipeA, but the test
in here was insufficient, falling back to pipe A if the area
intersection returned zero. Therefore, in the case where a window went
off to the top of the left of the screen, it would freeze, waiting on
the wrong vblank.
Fix this mess by checking the sarea for a crtc being zero sized, and in
that case always default to the other one.
|
|
intelMakeCurrent is called before intelWindowMoved (in fact, it calls
it), so calculation of the correct vblank crtc has not happened yet.
Fix this by making a function that fixes up a set of vblank flags and
call if from both functions.
|
|
We only allow combined depth+stencil renderbuffers so the complicated code
for splitting and combining separate depth and stencil buffers is no longer
needed.
|
|
|
|
|
|
The upstream linux kernel headers and libdrm kernel headers disagree on the
tag name for the sarea struct: _drm_i915_sarea vs drm_i915_sarea. They
both typedef it to drm_i915_sarea_t though, so just use that.
|
|
It's been broken and deprecated for a while, so it's time to die. This has the
wonderful benefit of cleaning up the code a fair amount; making it marginally
less twisty.
I'm unsure if the for loops in IntelWindowMoved are still needed.
|
|
This is part of the deprecated pageflipping infrastructure.
|
|
This avoids issues with dereferencing stale cliprects around intel_draw_buffer
time. Additionally, take advantage of cliprects staying constant for FBOs and
DRI2, and emit cliprects in the batchbuffer instead of having to flush batch
each time they change.
|
|
This lets us short-circuit when we're leaving the same cliprects in place,
which becomes quite common with metaops clears, and may be useful for some of
our FBO paths.
|
|
Makefile.template
|
|
|
|
This reverts commit 7c81124d7c4a4d1da9f48cbf7e82ab1a3a970a7a.
|
|
This reverts commit 53675e5c05c0598b7ea206d5c27dbcae786a2c03.
Conflicts:
src/mesa/drivers/dri/i965/brw_wm_surface_state.c
|
|
Conflicts:
src/mesa/drivers/dri/common/dri_bufmgr.c
src/mesa/drivers/dri/i965/brw_wm_surface_state.c
|
|
Accidentally pushed as part of the last commit.
|
|
Some buffer swap intel render buffer fields (pf_num_pages & vbl_pending) are
also used for page flipping, so enable the code that sets & updates them on
965. This allows buffer swaps and page flips to work on 965 and prevents hangs
in LOCK_HARDWARE in the buffer swap case due to an uninitialized vbl_pending
field.
Fixes FDO #16118.
|
|
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 .
|
