History log of /external/mesa3d/src/mesa/drivers/dri/i915/intel_buffers.c
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
3bcc780126ec3a479429a42befa27f141ebf8d48 23-Mar-2015 Ville Syrjälä <ville.syrjala@linux.intel.com> i915: Drop broken front_buffer_reading/drawing optimization

Bring the following commit over to i915:
commit ec542d74578bbef6b55125dd6aba1dc7f5079e65
Author: Eric Anholt <eric@anholt.net>
Date: Mon Mar 3 10:43:10 2014 -0800

i965: Drop broken front_buffer_reading/drawing optimization.

Not sure if it might fix anything, but since the i965 and i915 used to
share a bunch of that code, it would seem reasonable the same problems
could be present in the i915 code still, and the i965 approach is well
tested by now so bringing it over seems fairly safe.

No piglit regressions on 855.

v2: Rebase on _mesa_is_front_buffer_* refactor.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
/external/mesa3d/src/mesa/drivers/dri/i915/intel_buffers.c
66073ef438623f27dbbd01ba25189e5d4f0d9ae0 03-Mar-2014 Eric Anholt <eric@anholt.net> intel: When checking for updating front buffer reading, use the right fb.

It's the ctx->ReadBuffer that gets read from, not the ctx->DrawBuffer.
So, if you happened to have a ctx->ReadBuffer that was the winsys buffer,
and it had previously been intel_prepare_render()ed but not invalidated
since then, and you called glReadBuffer() to switch to front buffer
instead of back buffer reading on the winsys fbo while your drawbuffer was
a user FBO, you'd never get the front buffer's miptree fetched, and
segfault.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
/external/mesa3d/src/mesa/drivers/dri/i915/intel_buffers.c
877128505431adaf817dc8069172ebe4a1cdf5d8 17-Jan-2014 José Fonseca <jfonseca@vmware.com> s/Tungsten Graphics/VMware/

Tungsten Graphics Inc. was acquired by VMware Inc. in 2008. Leaving the
old copyright name is creating unnecessary confusion, hence this change.

This was the sed script I used:

$ cat tg2vmw.sed
# Run as:
#
# git reset --hard HEAD && find include scons src -type f -not -name 'sed*' -print0 | xargs -0 sed -i -f tg2vmw.sed
#

# Rename copyrights
s/Tungsten Gra\(ph\|hp\)ics,\? [iI]nc\.\?\(, Cedar Park\)\?\(, Austin\)\?\(, \(Texas\|TX\)\)\?\.\?/VMware, Inc./g
/Copyright/s/Tungsten Graphics\(,\? [iI]nc\.\)\?\(, Cedar Park\)\?\(, Austin\)\?\(, \(Texas\|TX\)\)\?\.\?/VMware, Inc./
s/TUNGSTEN GRAPHICS/VMWARE/g

# Rename emails
s/alanh@tungstengraphics.com/alanh@vmware.com/
s/jens@tungstengraphics.com/jowen@vmware.com/g
s/jrfonseca-at-tungstengraphics-dot-com/jfonseca-at-vmware-dot-com/
s/jrfonseca\?@tungstengraphics.com/jfonseca@vmware.com/g
s/keithw\?@tungstengraphics.com/keithw@vmware.com/g
s/michel@tungstengraphics.com/daenzer@vmware.com/g
s/thomas-at-tungstengraphics-dot-com/thellstom-at-vmware-dot-com/
s/zack@tungstengraphics.com/zackr@vmware.com/

# Remove dead links
s@Tungsten Graphics (http://www.tungstengraphics.com)@Tungsten Graphics@g

# C string src/gallium/state_trackers/vega/api_misc.c
s/"Tungsten Graphics, Inc"/"VMware, Inc"/

Reviewed-by: Brian Paul <brianp@vmware.com>
/external/mesa3d/src/mesa/drivers/dri/i915/intel_buffers.c
7f210bf5358443f38c1c7b758eaa28b37e09578a 20-Jun-2013 Eric Anholt <eric@anholt.net> i915: Remove miscellanous uncalled gen4 code from formerly shared files.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
/external/mesa3d/src/mesa/drivers/dri/i915/intel_buffers.c
733d32f3765be84a7e908df7e99a278cadcee853 20-Jun-2013 Eric Anholt <eric@anholt.net> i915: Fork the shared code from i965.

Of this 15000 lines of code in intel/, we've identified 4000 lines that
are trivially unnecessary for i915, and another 1000 that are pointless for
i965, and expect to find more as time goes on. Split the i915 driver off,
so that we can continue active development on i965 without worrying about
breaking i915.

Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Chad Versace <chad.versace@linux.intel.com>
Acked-by: Adam Jackson <ajax@redhat.com>
(and I hear second hand that idr is OK with it, too)
/external/mesa3d/src/mesa/drivers/dri/i915/intel_buffers.c
77a5bcaff43df8d54e0e0ef833726e4b41d7eb36 07-Nov-2007 Eric Anholt <eric@anholt.net> [intel] Move over files that will be shared with 965-fbo work.
/external/mesa3d/src/mesa/drivers/dri/i915/intel_buffers.c
3177b4e2cf7d2fff7428cb6057bebbe60ff5cc6c 30-Oct-2007 Michel Dänzer <michel@tungstengraphics.com> More vblank cleanups.

* Fix crash at context creation in most drivers supporting vblank.
* Don't pass vblank sequence or flags to functions that get passed the drawable
private already.
* Attempt to initialize vblank related drawable private fields just once
per drawable. May need more work in some drivers.
/external/mesa3d/src/mesa/drivers/dri/i915/intel_buffers.c
38fdb47d26055e19d50cd407266b56ed4317ae0a 29-Oct-2007 Jesse Barnes <jesse.barnes@intel.com> Refactor and fix core vblank support

Consolidate support for synchronizing to and retrieving vblank counters. Also
fix the core vblank code to return monotonic MSC counters, which are required
by some GLX extensions. Adding support for multiple pipes to a low level
driver is fairly easy, the Intel 965 driver provides simple example code (see
intel_buffers.c:intelWindowMoved()).

The new code bumps the media stream counter extension version to 2 and adds a
new getDrawableMSC callback. This callback takes a drawablePrivate pointer,
which is used to calculate the MSC value seen by clients based on the actual
vblank counter(s) returned from the kernel. The new drawable private fields
are as follows:
- vblSeq - used for tracking vblank counts for buffer swapping
- vblFlags - flags (e.g. current pipe), updated by low level driver
- msc_base - MSC counter from the last time the current pipe changed
- vblank_base - kernel DRM vblank counter from the last time the pipe changed

Using the above variables, the core vblank code (in vblank.c) can calculate a
monotonic MSC value. The low level DRI drivers are responsible for updating
the current pipe (by setting VBLANK_FLAG_SECONDARY for example in vblFlags)
along with msc_base and vblank_base whenever the pipe associated with a given
drawable changes (again, see intelWindowMoved for an example of this).

Drivers should fill in the GetDrawableMSC DriverAPIRec field to point to
driDrawableGetMSC32 and add code for pipe switching as outlined above to fully
support the new scheme.
/external/mesa3d/src/mesa/drivers/dri/i915/intel_buffers.c
efd03a278ae55b454509e9659c42899133983ebd 14-May-2007 Kristian Høgsberg <krh@hinata.boston.redhat.com> Replace open-coded major, minor, and patch version fields with __DRIversionRec.
/external/mesa3d/src/mesa/drivers/dri/i915/intel_buffers.c
b068af2f3b890bec26a186e9d0bdd3d44c17cd4d 10-Oct-2007 Kristian Høgsberg <krh@redhat.com> Key drm_i915_flip_t typedef off of the ioctl #define instead.
/external/mesa3d/src/mesa/drivers/dri/i915/intel_buffers.c
d99f6c4a2aa8207a2fbacd9b3a5ec87dd25ba496 28-Sep-2007 Jesse Barnes <jesse.barnes@intel.com> Go back to using old drm_i915_flip_t field name

This field shouldn't have been renamed in the first place. Go back to using
the old name so that the tree is backward and forward compatible again.
/external/mesa3d/src/mesa/drivers/dri/i915/intel_buffers.c
8cf9085bc7b96819d2bec1e749e15af58eefb2f3 24-Sep-2007 Eric Anholt <eric@anholt.net> Move i915tex driver into place as just i915.
/external/mesa3d/src/mesa/drivers/dri/i915/intel_buffers.c