| Age | Commit message (Collapse) | Author |
|---|
|
_glapi_Context and _glapi_Dispatch have different constness between
TLS and non-TLS builds.
|
|
|
|
Currently the test link uses -lGL to define the glapi symbols.
This makes it impossible to build DRI drivers on systems without
Mesa installed and without building the libGL from the Mesa tree
first.
Some automated build systems trigger this problem.
This commit removes -lGL and instead adds a dummy implementation of
glapi to dri_test.c
This, along with Kristian's commit, should fix all known regressions
due to the addition of unresolved symbol checking.
|
|
This is a different approach to solving this problem that the patch
I previously posted, and unlike that, should not cause any problems.
Right now undefined symbols in DRI drivers will still allow the
build to succeed.
As a result, people modifying drivers they cannot test risk creating
unloadable drivers with no easy way of automatically avoiding it.
For instance, the modifications to nv50 for context transfers caused
such an issue recently.
Unfortunately, just adding -Wl,--no-undefined doesn't work, because
the DRI drivers depend on glapi symbols, but do not depend on
libGL.so.1
Adding -lGL is not the correct solution since DRI drivers are not loaded
just by libGL, but also by X and possibly by other clients.
So, this patch simply tries to build an executable linked to the DRI
driver and to libGL.
If the DRI driver contains any undefined symbols not satisfied by its
dependencies or by libGL, this will fail.
This solution does not alter the built drivers, and does not significantly
slow down the build process.
All classic DRI drivers as well as all the Gallium drivers with configure
options compiled successfully with this change.
Thanks to Xavier Chantry <chantry.xavier@gmail.com> and
Michel Daenzer <michel@daenzer.net> for helping with this.
Signed-off-by: Luca Barbieri <luca@luca-barbieri.com>
Acked-by: Brian Paul <brian.e.paul@gmail.com>
|
|
|
|
allows to link with xmlconfig without dri_util, and has nothing drm-specific.
|
|
|
|
|
|
|
|
This is dri_util.c stripped from the drm-specific bits and will be used for
both classic and gallium swrast_dri.so
|
|
Signed-off-by: Jeff Smith <whydoubt@yahoo.com>
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
The break in the __DRI_ATTRIB_RENDER_TYPE case was accidentally
removed in commit 5cf2c5851bcd29c2d53bb04ab692b4b156f5a74d. This puts
it back.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
|
|
|
|
|
|
|
|
(cherry picked from commit 293f4d51b473783d5c5ab773a1c438e0a2fe46f2)
|
|
|
|
|
|
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 just threw it away before, but we haven't had a use for it yet.
|
|
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>
|
|
Conflicts:
src/gallium/auxiliary/draw/draw_context.c
src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c
src/gallium/auxiliary/pipebuffer/Makefile
src/gallium/auxiliary/pipebuffer/SConscript
src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
src/gallium/auxiliary/tgsi/tgsi_scan.c
src/gallium/drivers/i915/i915_surface.c
src/gallium/drivers/i915/i915_texture.c
src/gallium/drivers/llvmpipe/lp_setup.c
src/gallium/drivers/llvmpipe/lp_tex_sample_c.c
src/gallium/drivers/llvmpipe/lp_texture.c
src/gallium/drivers/softpipe/sp_prim_vbuf.c
src/gallium/state_trackers/xorg/xorg_dri2.c
src/gallium/winsys/drm/intel/gem/intel_drm_api.c
src/gallium/winsys/drm/nouveau/drm/nouveau_drm_api.c
src/gallium/winsys/drm/radeon/core/radeon_drm.c
src/gallium/winsys/drm/vmware/core/vmw_screen_dri.c
src/mesa/state_tracker/st_cb_clear.c
|
|
Signed-off-by: Matthias Hopf <mhopf@suse.de>
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
They are not used at all.
|
|
Conflicts due to DRI1 removal:
src/mesa/drivers/dri/intel/intel_context.c
src/mesa/drivers/dri/intel/intel_screen.c
|
|
Support the new DRI2 protocol request, DRI2SwapBuffers, in both direct
and indirect rendering context. This request allows the display server
to optimize back->front swaps (e.g. through page flipping) and allows us
to more easily support other GLX features like swap interval and the OML
sync extension in DRI2.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
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.
|
|
Conflicts:
src/mesa/drivers/dri/unichrome/via_ioctl.c
src/mesa/drivers/dri/unichrome/via_screen.c
src/mesa/main/version.h
src/mesa/state_tracker/st_atom.c
|
|
|
|
This is really for MESA_FORMAT_XRGB8888. Clearly spantmp2.h needs some
re-work. Any volunteers?
|
|
(cherry picked from commit 919898e92fa23ff71a59d86a46ff0886a6f34e4d)
|
|
(cherry picked from commit 364070b1f2b08d43fb205ec198894a35bec6b2f3)
|
|
|
|
|
|
Fixes unresolved symbol bswap_16 on non-glibc or little endian glibc platforms.
|
|
|
|
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
|
|
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
|
|
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>
|
|
Now pass a specific MESA_FORMAT_x token to indicate the renderbuffer's
format. This is better than passing a GLenum and having to guess the
specific format.
I'm unable to test all the drivers, but any issues should be easy to fix.
|
|
As per FDO #17889.
|
|
|
|
|
|
|
