| Age | Commit message (Collapse) | Author |
|---|
|
All these pointers are in the __DRIcontext struct, which we point to.
|
|
I keep finding the desire to force this path to debug it instead of
cooking up goofy-looking testcases to do so.
|
|
The default viewport is the window rectangle, which is set up by
_mesa_make_current(). To be able to do that we need to get the
window dimension (and buffers) first, so we have to call
intel_prepare_render() before we can call into _mesa_make_current().
Fixes #26676 and #26678.
|
|
Shaves 60k off the driver from removing the broken spans code. This
means we now require 2.6.29, which seems fair given that it's a year
old and we've removed support for non-KMS already in the last release
of 2D.
|
|
|
|
|
|
|
|
This restores old behaviour, where we end up doing a DRI2GetBuffers()
call from intelMakeCurrent(). The idea was that we could do this
lazily, just before we start rendering. However, if we don't do the
DRI2GetBuffers() round-trip we don't get the drawable size and higher
level mesa ends up short-cutting a number of GL calls, such as glClear().
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This way, if we get an invalidate as we update the buffers, we
don't clobber the drawable stamp and ignore the invalidate.
Pointed-out-by: Francisco Jerez
|
|
|
|
This uses a stamp mechanisms to mark the DRI drawable as invalid.
Instead of immediately updating the buffers we just bump the drawable
stamp and call out to DRI2GetBuffers "later".
"Later" used to be at LOCK_HARDWARE time, and this patch brings back
callouts at the points where we used to call LOCK_HARDWARE. A new function,
intel_prepare_render(), is called where we used to call LOCK_HARDWARE,
and if the buffers are invalid, we call out to DRI2GetBuffers there.
This lets us invalidate buffers only when notified instead of on
every glViewport() call. If the loader calls the DRI invalidate
entrypoint, we disable viewport triggered buffer invalidation.
Additionally, we can clean up the old viewport mechanism a bit,
since we can just invalidate the buffers and not worry about
reentrancy and whatnot.
|
|
When a buffer invalidation event is received from the X server, the
"invalidate" hook of the DRI2 flush extension is executed: A generic
implementation (dri2InvalidateDrawable) is provided that just bumps
the "pStamp" sequence number in __DRIdrawableRec.
For old servers not supporting buffer invalidation events, the
invalidate hook will be called before flushing the fake front/back
buffer (that's typically once per frame -- not a lot worse than the
situation we were in before).
No effort has been made on preserving backwards compatibility with
version 2 of the flush extension, but I think it's acceptable because
AFAIK no released stack is making use of it.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
|
|
|
|
Now that we track the global name in struct intel_region, we can just
look it up there.
|
|
|
|
|
|
|
|
The server side does the throttling on our behalf now by putting the
client to sleep, so we don't need our previous hacks for limiting the
number of outstanding frames. Same effect as
7d4e674b212c9dc6408c13913a399bd4a2b9a1e3.
|
|
done."
This reverts commit 7d4e674b212c9dc6408c13913a399bd4a2b9a1e3. It broke
throttling in the non-new-DRI2 case.
|
|
Conflicts:
src/mesa/drivers/dri/intel/intel_screen.c
src/mesa/drivers/dri/intel/intel_swapbuffers.c
src/mesa/drivers/dri/r300/r300_emit.c
src/mesa/drivers/dri/r300/r300_ioctl.c
src/mesa/drivers/dri/r300/r300_tex.c
src/mesa/drivers/dri/r300/r300_texstate.c
|
|
|
|
Previously for frame throttling we would wait on the first batch after
a swap before emitting another swap, because we had no hook after a
swap was emitted. This meant that if an app managed to squeeze
everything it for a frame had into one batch, it would lock-step with
the GPU. With the swapbuffers changes, we now have the entrypoint we
want.
This takes the WoW intro screen from 25% GPU idle and visibly jerky to
4-5% GPU idle and rather smooth. Other apps such as OpenArena have
run into this problem as well.
|
|
Conflicts due to DRI1 removal:
src/mesa/drivers/dri/intel/intel_context.c
src/mesa/drivers/dri/intel/intel_screen.c
|
|
Needed to support the SwapBuffers code properly.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
|
|
|
|
With the vsync fields no longer relevant and by refactoring the code
to no longer use color_rb[0-1] we can just use struct gl_framebuffer
directly.
|
|
|
|
Everything this functions does under DRI2 is also taken care of
by intel_draw_buffer(), which is always called where intelWindowMoved()
is called.
|
|
|
|
|
|
As part of the DRI driver interface rewrite I merged __DRIscreenPrivate
and __DRIscreen, and likewise for __DRIdrawablePrivate and
__DRIcontextPrivate. I left typedefs in place though, to avoid renaming
all the *Private use internal to the driver. That was probably a
mistake, and it turns out a one-line find+sed combo can do the mass
rename. Better late than never.
|
|
Noticed by clang.
|
|
Shaves 400 bytes or so from i915_dri.so.
|
|
Saves ~2KB of code.
|
|
Saves ~480 bytes of code.
|
|
|
|
Conflicts:
src/mesa/main/version.h
|
|
|
|
This really isn't supported at this point. GEM's been in the kernel for
a year, and the fake bufmgr never really worked.
|
|
|
|
|
|
gen2/3/4 are easier to say than "8xx, 915-945/g33/pineview, 965/g45/misc",
and compares on generation are often easier than stringing together a bunch
of chipset checks.
|
|
We only need it when drawing to the front buffer, which we never do for
DRI2. No significant performance difference, but the flush is definitely
gone from the end of every batchbuffer.
|
|
Conflicts:
src/mesa/drivers/dri/radeon/radeon_fbo.c
src/mesa/drivers/dri/s3v/s3v_tex.c
src/mesa/drivers/dri/s3v/s3v_xmesa.c
src/mesa/drivers/dri/trident/trident_context.c
src/mesa/main/debug.c
src/mesa/main/mipmap.c
src/mesa/main/texformat.c
src/mesa/main/texgetimage.c
|
|
|
|
Per the GLX spec, when changing rendering contexts, the old context
should first be flushed.
|
|
|
|
_ActualFormat is replaced by Format (MESA_FORMAT_x).
ColorEncoding, ComponentType, RedBits, GreenBits, BlueBits, etc. are
all replaced by MESA_FORMAT_x queries.
|
|
Conflicts:
src/gallium/auxiliary/util/u_cpu_detect.c
|
