Just use flush_frontbuffer directly. The flush_frontbuffer routine has
been somewhat devalued recently, but it is actually just the right
interface for our needs.
It is in pipe_screen, meaning that any wrapping (eg trace module)
will get properly unwrapped before we try and use the pipe_surface
argument for real.
If a particular co-state-tracker needs to implement this itself, it
should organize a way to allow the winsys to call back up to its
level, rather than hijacking the driver-supplied implementation.
Currently there are still at least two functions bundled up inside the
winsys concept:
a) that of a backend resource manager, sometimes capable of performing
present() operations,
b) the initialization code/routine for the whole driver stack.
The inclusion of (b) makes it difficult to share implementations of
(a) between different drivers. For instance, a clean xlib winsys
could be of use for software-rasterized VG, GLES, EGL, etc, stacks.
But that is only true as long as there is no dependency from the
winsys to higher level code, as would be the case when we include (b)
in this component.
This change creates a new gallium/targets subtree, specifically for
implementing the glue needed to build individual driver stacks, and
moves that code out of a single example winsys, namely xlib.
Other drivers continue to build unchanged, but hopefully can migrate
to this structure over time.
Promote the llvmpipe winsys more or less unchanged to
state_trackers/sw_winsys.h.
Some minor breakages:
- softpipe::texture_blanket is broken, but scheduled for removal anyway.
- haven't fixed up g3vdl yet.
The break in the __DRI_ATTRIB_RENDER_TYPE case was accidentally
removed in commit 5cf2c5851b. This puts
it back.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Only tested this on my rv530 with R300_NO_TCL=1, but it works there
at least. It would be nice to fix the tex_offset by chaning the vertex
program on tcl to read from offset 6 but this isn't really necessary.
Signed-off-by: Dave Airlie <airlied@redhat.com>
at least on the r500 we get a lockup unless I do this, the compiler
seems to fail to compile and we just get a null fp.
Signed-off-by: Dave Airlie <airlied@redhat.com>
I wasn't careful enough when removing support for GCC versions earlier
than 3.3.0. I could have sworn that I compile tested before pushing,
but apparently not. FAIL.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Mesa now requires GCC 3.3.0 or later. See the following thread from
the mesa3d-dev mailing list for more details:
http://marc.info/?t=126748568900005&r=1&w=2
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Check if the native blit formats are supported, if not,
attempt to use an alternate format.
Skip 3, >4 bpp as per comments from mcencora on irc.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Now that color-index support is removed from t_dd_tritmp.h and
t_dd_unfilled.h, drivers no longer need define HAVE_RGBA.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
The code removal and the re-indent were done together for this one
because the cause of the affected code blocks is much, much smaller
than in t_dd_tritmp.h.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Since there is no color-index rendering, it is impossible to update
this value. Just return the initial setting and be happy.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
These are used to inform the driver of the clear value for color-index
buffers and to control write-masking of bits in color-index buffers.
No driver use or need (not even Nouveau) these interfaces.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
After all the recent color-index rendering removal,
_swrast_logicop_ci_span is no longer used anywhere.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
After all the recent color-index visual support removal,
_mesa_add_color_index_renderbuffers is no longer used anywhere.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.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>
