| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This is an expected behavior when we're testing for the presence of
new kernel features.
|
|
With relaxed relocation checking in the kernel, we can specify a
negative delta (i.e. pointing outside of the target bo) in order to fake
a range in a large buffer. We only then need to upload the elements used
and adjust the buffer offset such that they correspond with the indices
used in the DrawArrays.
(Depends on libdrm 0209428b3918c4336018da9293cdcbf7f8fedfb6)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If another thread bound a context to the drawable then unbound it, the
driContextPriv would end up NULL.
With the previous two fixes, this fixes glx-multithread-makecurrent-2,
despite the issue not being about the multithreaded makecurrent.
|
|
It's faster. Not only is the memcpy more efficiently performed in the
kernel (making up for the system call overhead), but by not using mmap
we remove the greater overhead of tracking the vma of every batch.
And it means we can read back from the batch buffer without incurring
the cost of a uncached read through the GTT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
|
|
|
|
This requires shuffling the driconf XML macros around, since they use
true and false tokens expecting them to not get expanded to anything.
|
|
Sometimes I'm on the train and want to just read what's generated
under INTEL_DEBUG=vs,wm for some code on another generation. Or, for
the next gen enablement we'll want to dump aub files before we have
the actual hardware. This will let us do that.
|
|
|
|
|
|
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>
|
