| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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.
|
|
|
|
This really isn't supported at this point. GEM's been in the kernel for
a year, and the fake bufmgr never really worked.
|
|
We weren't choosing the right XRGB span functions for reading the
framebuffer. XRGB formats still aren't turned on yet though.
|
|
Pass a gl_format to intel_create_renderbuffer() instead of GLenum.
Add cases for MESA_FORMAT_XRGB8888 textures and renderbuffers.
However, we don't yet create any renderbuffers or textures with that
format. It seems the default alpha value is zero instead of one.
Need to investigate that first.
|
|
This enables the remap table in core. driInitExtensions is adapted to
use the remap table. All uses of extension_helper.h are replaced by
remap_helper.h. The chicken-egg problem of the DRI drivers is also
solved.
It is now also possible to pass NULL extensions to driInitExtensions.
It will cause driInitExtensions to map all known functions. This
functionality is used by software drivers and EGL_i915.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
|
|
This is useful for enabling our GLSL testcases using the 2.0 entrypoints
even though we don't have full GL 2.0.
|
|
Other vendors have enabled ARB_fragment_shader as part of OpenGL 2.0
enablement even on hardware like the 915 with no dynamic branching or
dFdx/dFdy support. But for now we'll leave it disabled because we don't
do any flattening of ifs or loops, which is rather restrictive.
This support is not complete, and may be unstable depending on your shaders.
It passes 10/15 of the piglit glsl tests, but hangs on glean glsl1.
|
|
This reverts commit b8e638d4895d2d342306bb6443a455f73903ce20.
Now that the known hangs and misrendering issues are fixed, I'm ready to
start encouraging it by default again.
|
|
Conflicts:
Makefile
configs/default
docs/relnotes.html
src/mesa/main/version.h
|
|
(cherry picked from commit 6d66f23c50ebe8f973757b6fd1b81c9b7920c447)
|
|
|
|
|
|
Valgrind doesn't know that a successful getparam sets the target of the
pointer, so just set the value beforehand.
|
|
(cherry picked from commit 42e9bde0fa2276b8f5bb434328eea7665794b127)
|
|
One warning message:
drm_i915_getparam: -22
was still being sent to fprintf(). This causes all Piglit tests to fail,
even with MESA_DEBUG=0.
Using _mesa_warning() to emit the message allows the general Mesa controls
for messages like this to be applied.
(cherry picked from commit bc3270e99f5c39544aaf831742db14796ab83a6a)
|
|
Fixes memory leak when destroying framebuffers.
|
|
I haven't fixed all the regressions yet, and it'll be easy to re-enable when
the known problems are fixed.
|
|
Conflicts:
src/mesa/main/api_validate.c
|
|
The early Z stuff is supposed to be unsafe without some more work in the
enable/disable path (in particular, how do we want to get it disabled on
the way out to the X Server?), but at the moment is 6% in OA.
|
|
|
|
This is about a 30% performance win in OA with high settings on my GM45,
and experiments with 915GM indicate that it'll be around a 20% win there.
Currently, 915-class hardware is seriously hurt by the fact that we use
fence regs to control the tiling even for 3D instructions that could live
without them, so we spend a bunch of time waiting on previous rendering in
order to pull fences off. Thus, the texture_tiling driconf option defaults
off there for now.
|
|
One warning message:
drm_i915_getparam: -22
was still being sent to fprintf(). This causes all Piglit tests to fail,
even with MESA_DEBUG=0.
Using _mesa_warning() to emit the message allows the general Mesa controls
for messages like this to be applied.
|
|
This speeds up OA on my GM45 by 21% (more than the original CPU cost of
the upload path). We might still be able to squeeze a few more percent out
by avoiding repeatedly mapping/unmapping buffers as we upload elements into
them.
|
|
|
|
This requires upgrading the interface so that the argument to
glXBindTexImageEXT isn't just dropped on the floor. Note that this only
fixes the accelerated path on Intel, as Mesa's texture format support is
missing x8r8g8b8 support (right now, GL_RGB textures get uploaded as a8r8gb8,
but in this case we're not doing the upload so we can't really work around it
that way).
Fixes bugs with compositors trying to use shaders that use alpha channels, on
windows without a valid alpha channel. Bug #19910 and likely others as well.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
|
|
This can improve debugging with INTEL_DEBUG=batch,sync by giving smaller
batchbuffers.
|
|
I keep wanting to hack this knob in as a one-time thing, so it seemed useful
to have all the time.
|
|
While it's a nice idea to be able to allow clients to choose a smaller
(or bigger for 16bpp screens!) depth size, right now DRI2 hands back a buffer
with a size that matches the drawable, rather than being based off of the
visual. This led to problems in readback as parts of the driver disagreed
on what format the depth buffer was really in.
Fixes the remainder of bug #19447.
|
