Age | Commit message (Collapse) | Author |
|
Conflicts:
src/mesa/drivers/dri/i915tex/intel_buffers.c
src/mesa/drivers/dri/i915tex/intel_context.c
src/mesa/drivers/dri/i915tex/intel_fbo.c
src/mesa/drivers/dri/i915tex/intel_pixel_draw.c
|
|
Z testing now works with i915 driver.
Add gl_renderbuffer::surface pointer (and reverse pointer).
Remove intel_surface and xmesa_surface types - no longer used.
|
|
|
|
|
|
|
|
|
|
Must not change to/from swrast after Render.Start or bad things will happen.
(Driver will still somewhat incorrectly report an implementation error,
and apps can't really figure out if a prog is natively supported as validation
is later - could try doing it earlier to give some hint at least, even though
native status may still change later due to fog etc.)
|
|
into softpipe_0_1_branch
|
|
|
|
|
|
|
|
Make sure that we bind the right buffer (draw or read) when rebinding
the window framebuffer (the api doesn't allow binding different draw and
read buffers at the same time, but the default window framebuffer is basically
2 fb objects, one for read, one for write, which can be different). Pass both
of these two down the driver api (no driver uses this right now).
|
|
xdemos/shape)
|
|
remove some already ifdefed out, no longer functional and used code.
Don't do our own scissor clipping in the pixeldraw/copy paths,
as meas already does that for us...
|
|
manywin got broken (when intelPageflip got no longer called).
Make sure that intelFlush is getting called when a context gets unbound,
to handle later swapbuffer calls on that context's drawable better.
Related, fix non-current cliprects getting used on unbound drawables.
|
|
|
|
|
|
|
|
Make sure that we bind the right buffer (draw or read) when rebinding
the window framebuffer (the api doesn't allow binding different draw and
read buffers at the same time, but the default window framebuffer is basically
2 fb objects, one for read, one for write, which can be different). Pass both
of these two down the driver api (no driver uses this right now).
|
|
functional anyway) rotation code
|
|
xdemos/shape)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
pack->alignment doesn't matter usually if the image is sufficiently aligned
anyway. Speeds up some tests/readrate cases by a factor of 100 (since
the pack->alignment default which noone ever bothers to change is 4).
|
|
|
|
the framebuffer objects attached to drawables can have invalidate state
associated with them, since for the window framebuffer this is per-context
state and not per-fbo state. Since drivers may rely on that information
(otherwise would need to check if currently the window-framebuffer is
bound in a lot of places) fix it up in _mesa_make_current (ugly).
|
|
|
|
|
|
copyTexSubimage
|
|
move drawable validation back to where it was now that the driDrawable
information isn't used directly anymore.
Fix bogus fb updates (the context we get for SwapBuffer processing
may not have the drawable being processed attached!)
glthreads behaves a bit better but still not correct.
|
|
driDrawable information now isn't used in most parts of the driver.
makecurrent only updates fb information when the context is new
(driDrawable is still updated by the dri common code).
|
|
|
|
Move buffer resize check to immediately after swapbuffers.
Update cliprects inside the locked region of swapbuffers.
|
|
don't update driDrawable information until later at all
(blit needs fixing).
|
|
|
|
still doesn't work quite right (resize).
Fake frontbuffer doesn't copy in real frontbuffer.
Don't even think about doing rotation/page flip/triple buffering for now...
More cleanups needed (fake cliprects etc.)
|
|
|
|
Allocate and use private back and z/stencil buffers.
This is still very broken.
|
|
The previous procedure would often result in a GPU lockup.
|
|
This avoids superfluous waits for vblank timing out under some circumstances.
|
|
The t_dd_tritemp.h code can emit GL_QUADS primitives. We need to catch
that case to determine if polygon stipple should be enabled.
Fixes bug reported by Carlos Diógenes on 4 July 2007.
|
|
into softpipe_0_1_branch
|
|
Need to turn off FRAG_BIT_COL0 in swrast->_ActiveAttribMask when doing
glRead/CopyPixels to prevent the user's colors from getting overwritten
when a fragment program is active.
This was happening in the DRI drivers when MaintainTexEnv program was
used (the texenv fragment program was enabled when _swrast_DrawPixels was
called).
This still isn't an ideal solution, but fixes things for now.
|