| Age | Commit message (Collapse) | Author |
|---|
|
Conflicts:
src/mesa/state_tracker/st_gen_mipmap.c
src/mesa/state_tracker/st_texture.c
|
|
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
|
|
The idea would be that you could have multiple send messages going on
if nothing depended on the previous message's results and you used a
different send message. The problem is that the later send requires
the VUE handle returned by the first send's allocate 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.
|
|
|
|
adapt to blit changes, and also handle a bit more msaa state in theory
(incomplete, doesn't handle resolves in any way for now).
|
|
The linux-debug target builds...
|
|
This is similar to the GL_QUAD_STRIP -> TRIANGLE_STRIP optimization --
the GS usage to split the quads into tris is a huge bottleneck, so a
quick check improves glean blendFunc time massively (width * height of
the window of single-pixel GL_QUADS, many many times). This may also
end up helping with cairo performance, which sometimes ends up drawing
a single quad.
|
|
While sometimes rendering occurs in the form of blits for TexImage, it
doesn't interact with the window system renderbuffers, so skip it.
|
|
|
|
|
|
|
|
|
|
|
|
This removes references to symbols in draw module for OpenGL ES build.
As OpenGL ES does not support feedback/selection mode, draw module is
used in pathes that will never be reached. However, if the symbols are
referenced, it will bloat the final shared libraries unnecessarily.
This is serious when LLVM is enabled.
|
|
With the omit list gone, there are not too many differences in building
core mesa and ES overlay. Remove the mesa/es and build both of them in
src/mesa/Makefile.
|
|
vbo/vbo_save* are the last members on the omit list. Test FEATURE_dlist
in the sources and remove the omit list.
|
|
This allows atifragshader.h to be used without knowing if
FEATURE_ATI_fragment_shader is enabled. As a result, atifragshader.c is
removed from the omit list in ES overlay.
|
|
All ES overlay sources have been merged into core Mesa. Not much is
left in sources.mak so merge it into Makefile.
|
|
Remove sources that are feature-aware from the omit list. x86 -O0 build
is ~12KiB smaller afther making those sources feature-aware.
Also, remove get.c from the omit list as get_es[12].c have been merged
to it.
|
|
This change allows st_cb_drawtex.h to be used without knowing if
FEATURE_OES_draw_texture is enabled.
|
|
This allows condrender.c to be compiled without FEATURE_queryobj.
|
|
This change allows st_cb_blit.h to be used without knowing if
FEATURE_EXT_framebuffer_blit is enabled.
|
|
This change allows st_cb_queryobj.h to be used without knowing if
FEATURE_queryobj is enabled.
|
|
Make st_cb_feedback.h FEATURE_feedback aware and st_cb_rastpos.h
FEATURE_rastpos aware. Move creation of selection/feedback draw context
to st_init_draw.
|
|
This change allows st_cb_{bitmap,drawpixels}.h to be used without
knowing if FEATURE_drawpix is enabled.
|
|
This change allows st_cb_accum.h to be used without knowing if
FEATURE_accum is enabled.
|
|
This allows transformfeedback.h and st_cb_xformfb.h to be included and
used without knowing if FEATURE_EXT_transform_feedback is enabled. Fix
build of ES overlay.
|
|
|
|
|
|
|
|
|
|
|
|
This fixes crashes with the memory debugging routines on Windows.
NOTE: This is a candidate for the 7.8 stable branch
|
|
|
|
|
|
|
|
|
|
Now that transfers are context operations it is the driver's
responsibility to ensure that transfers happen in order with all other
context operations, so flushes and finishes inside Mesa should be no
longer necessary. The attached patch implements that.
This should proportionate significant improvements for hardware drivers
which are able to stream transfers in the command buffers.
You can use the softpipe/llvmpipe_flush_resource() as reference
implementation of the worst case scenario, where the driver is not able
to streamline transfers. But the expectation is that driver
implementators will want to avoid flushing as much as possible.
|
|
From http://www.opengl.org/registry/api/glext.h
GLAPI void APIENTRY glBindTransformFeedback (GLenum target, GLuint id);
Fixes MinGW build.
|
|
Includes GL_ARB_transform_feedback2 which encapsulates transform feedback
state in objects.
|
|
|
|
|
|
This was missed in commit c4775a27e3aaa2006b98f225387499b79bc609ef.
Fixes i915 build.
|
|
Now that intel_flush() deosn't use the needs_mi_flush argument, we can
finally drop one of the two flush functions.
|
|
Without this patch, any old intel_flush() call will cause a round trip to
the server and do a copy from fake to real front. We only actually
guarantee that frontbuffer results show up when glFlush() ia called, so
move the flushing to intel_glFlush().
We also need to flush fake to front before getting new buffers, but
we just handle that manually.
|
|
When we call intel_prepare_render() from intelReadPixels(), we'll mark
the front buffer dirty. That's silly, since we're only reading from it
and marking it dirty will cause us to copy from fake front to front
eventually.
Just clear the dirty flag after doing the read.
|
|
Now that we have intel_prepare_render() in place, we can use it to mark
the front buffer dirty if we're rendering to the front buffer once we
get there.
|
|
|
