| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
We can't expect to have a context when this is called, and we don't need one
so just require a __DRIscreen instead.
Reported by Yu Dai <yu.dai@intel.com>
|
|
|
|
|
|
Now that we have glsl2 with if flattening in place, most shaders will
just work. Remaining failing shaders will mostly be due to loop
unrolling (in progress), some possible if flattening failures in
inlining functions (planning on fixing), and the register/instruction
count limits.
While the GLSL and GLSL-ES specs say that shaders shouldn't fail to
compile/link due to register/instruction limits, in practice we're not
the first vendor to expose GLSL on hardware with these limitations.
The benefit to application developers of providing a better language
for GPU programming is greater than the pain of having to handle
instruction limits (which they had to for ARB_fp on this hardware
anyway)
|
|
Before we would throttle in the flush callback prior to round-tripping
to the server to do copyregion or swapbuffer. Now, instead just note
that we need to throttle and do it in intel_prepare_render(), which
will be called after receiving the response from the server but before
we start rendering the next frame. Even if the server also throttles
us in swapbuffer, this just makes the throttling a no-op when we hit
intel_prepare_render(). With that we can drop the
using_dri2_swapbuffers hack and just always throttle.
|
|
Conflicts:
src/mesa/drivers/dri/common/dri_util.h
|
|
|
|
|
|
|
|
Add a new DRI2 configuration query extension. Allows for DRI2 client
code to query for common DRI2 configuration options.
|
|
|
|
|
|
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 now passes piglit testcases, and shows performance improvements
on openarena. Blit-heavy apps may see degradation, but the
expectation is that the common case of 3D rendering will see
significant wins.
This regresses gen-teximage on my 855, and no piglit tests on my 945.
|
|
This improves tiled texture performance of OA on my 945 from 25.3fps
to 29.0fps, whereas untiled is 28.2fps, by avoiding stalls for fence
register changes.
|
|
Previously we'd use the current renderbuffer.
|
|
|
|
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>
|
|
|
|
|
|
|
|
|
|
We can't always guarantee that the swap will happen by exchange, so we
can't expose this mode. GLX_SWAP_UNDEFINED_OML already covers the
case where the swap *might be* by exchange.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
|
|
Expose one config per color depth that includes accumulation buffer.
We could probably expose only one config with accumulation buffer, but
that would require figuring out the actual color depth. This is
easier and only exposes 2 useless configs.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
|
|
Modify the interface to driCreateConfigs allowing drivers to not
expose configs with an accumuation buffer. All of the drivers calling
function have been updated to pass true for the accumulation
selector. This maintains the current behavior.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Corbin Simpson <MostAwesomeDude@gmail.com>
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
|
|
This should make things easier for drivers wanting to work with a
"subclass" of gl_framebuffer.
The complementary "_mesa_initialize_framebuffer" function is now
called "_mesa_initialize_window_framebuffer" for the sake of
symmetry.
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
|
|
Now that LOCK_HARDWARE is gone, we don't have a convenient place to
update the renderbuffers everywhere we need them. So grab new buffers
when we invalidate the old ones until we optimize things further.
|
|
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.
|
|
|
|
|
|
|
|
|
|
The DDX driver stopped supporting DRI1 so we're dropping support for
that from the DRI driver too.
|
|
This lets the individual drivers select which extensions to advertise.
Specifically, most drivers (tdfx, sis, savage etc) don't support DRI2
but the shared extension list in dri_util.c does list the DRI2 extension.
Pushing the list into the drivers, lets us avoid listing the DRI2
extension for drivers that don't support it.
|
