| Age | Commit message (Collapse) | Author |
|---|
|
Fixes an issue when different displays are used on different threads.
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
Just add the gl_api parameter to _mesa_initialize_context().
|
|
This code was for the old GLcore build of the software rasteriser. The
X server switched to a DRI driver for software indirect GLX long ago.
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
Remove the rgbMode and indexBits parameters from _mesa_create_visual
and _mesa_initialize_visual. These values are now hardcoded to
GL_TRUE and 0.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
|
|
|
|
|
|
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>
|
|
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 reverts commit 651cffd626a82d9bf539437ca4bdf8ea4b396fab.
The commit inadvertantly introduced a new gallium dependency on the meta code.
|
|
|
|
|
|
The wording of these two is exactly the same, except for the issue
"Can fragments with wc<=0 be generated when this extension is supported?",
which idr thinks is a non-issue for us.
|
|
This currently doesn't include fixing up the cliptests in the assembly
paths to support ARB_depth_clamp, so enabling depth_clamp forces the C path.
|
|
|
|
|
|
|
|
Remove all references to aux buffers 1..3. Keep AUX0 around for now just
in case, but it'll probably go too someday. I don't know of any OpenGL
drivers since the IRIX days that support aux color buffers.
|
|
Use loops to consolidate lots of texture object code.
|
|
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
Move the include/GL/xmesa*.h files to src/mesa/drivers/x11/ so they're no
longer considered public.
|
|
|
|
|
|
|
|
|
|
|
|
Only build tested.
|
|
Could be done more efficiently... but works.
|
|
This is to unify the xmesa code across xserver DDX'es. The call is intented for
XGL, but it does not hurt to call for other DDX'es. In fact it was not guarded
against XGL when it was first added in xserver.
|
|
mainly drop 'client' argument from initialize_visual_and_buffer().
|
|
|
|
|
|
|
|
This reverts commit 2a2f8d806f74619f0a7cf97fdc7f7b3ad1cad81b.
|
|
glide is no longer compiled with stand-alone libGL, so this will not link.
There are still the glide config files. some code in demos and the
GLX_MESA_set_3dfx_mode code which could be removed.
|
|
This uses xmesa.h as the GLcore interface and avoids adding an explicit GLcore
inteface which would not be a proper interface anyway.
It puts the declarations of the three functions specific for XMesa/XFree86 in
xmesa.h, we can push them down to xmesa_xf86.h if hiding behind XFree86Server
ifdef's is not enough.
|
|
|
|
Drop XMesaSetVisualDisplay(), XMesaReset(), no longer used.
Add XMesaCopyContext() and move the GlxSetRenderTables() call for XGL within
XMesaForceCurrent(). This is to make xserver/GL/mesa/X/xf86glx.c unaware of
Mesa internals.
Also, clean some ifdef's to make it clear that USE_XSHM and XFree86Server are
mutually exclusive.
Lastly,
- move gcstruct.h from glxheader.h up to xmesa_xf86.h since it calls *gc->ops
- drop GL/glxtokens.h from xm_api|dd.c, GLX tokens come from glcore.h and are
used irrelevant of XFree86.
|
|
Nicolai writes:
When the pixmap pixel format has no alpha channel, the x11 driver
(software rendering) adds a wrapped alpha channel on request.
During SwapBuffers, this alpha channel is not copied from back to
front, which means that the front buffer doesn't really contain the
contents that the back buffer previously contained.
A subsequent glReadPixels from the front buffer will return an
incorrect result. The following patch attempts to fix this.
|
|
In xmesa_check_and_update_buffer_size() handle xmctx==NULL correctly: still
call _mesa_resize_framebufer(). If we don't we can wind up in a situation
where the framebuffer size is non-zero but an attached renderbuffer size
is still initialized to zero. This inconsistancy can later cause problems.
Check for zero-size renderbuffers in update_color_draw_buffers() and
update_color_read_buffer().
See bug 7205.
|
|
|
|
|
