summaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/i965/intel_buffer_objects.c
Commit message (Collapse)AuthorAgeFilesLines
* i965: use _mesa_delete_buffer_objectNicolai Hähnle2016-01-071-1/+1
| | | | | | | | | This is more future-proof, plugs the memory leak of Label and properly destroys the buffer mutex. Reviewed-by: Marek Olšák <marek.olsak@amd.com> Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
* Revert "i965/wm: use proper API buffer size for the surfaces."Ilia Mirkin2016-01-051-1/+0
| | | | | | | | | | | This reverts commit 8cf2e892fca20c4776b4a07c39918343cb2d4e0e. It's entirely bogus to attempt to store anything about the binding in the buffer object itself, which might be bound any number of times. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Samuel Iglesias Gonsálvez <siglesias@igalia.com> Cc: Marta Lofstedt <marta.lofstedt@intel.com> Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
* i965/wm: use proper API buffer size for the surfaces.Samuel Iglesias Gonsálvez2016-01-041-0/+1
| | | | | | | | | | | | | | | Commit 5bb5eeea fixes a bug indicating that the surfaces should have the API buffer size. Hovewer it picked the wrong value. This patch adds a new variable, which takes into account glBindBufferRange() values. This patch fixes the following CTS regressions: ES31-CTS.shader_storage_buffer_object.advanced-unsizedArrayLength-cs-std430-vec-bindrangeOffset ES31-CTS.shader_storage_buffer_object.advanced-unsizedArrayLength-cs-std430-vec-bindrangeSize Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com> Reviewed-by: Marta Lofstedt <marta.lofstedt@intel.com>
* i965: Implement DriverFlags.NewShaderStorageBufferIago Toral Quiroga2015-09-251-0/+2
| | | | | | | | We use the same dirty state for SSBOs and UBOs because they share the same infrastructure. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
* i965: Fix typos in licenseIan Romanick2015-09-101-2/+2
| | | | | | | | | | | | | | | | grep -lr 'sub license' | while read f; do \ sed --in-place -e 's/sub license/sublicense/' $f ;\ done grep -lr 'NON-INFRINGEMENT' | while read f; do \ sed --in-place -e 's/NON-INFRINGEMENT/NONINFRINGEMENT/' $f ;\ done As noted by Matt, both of these changes match the MIT license text found at http://opensource.org/licenses/MIT. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Acked-by: Matt Turner <mattst88@gmail.com>
* i965: Remove horizontal bars from file header commentsIan Romanick2015-09-101-4/+2
| | | | | | | Why was that ever a thing? Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Acked-by: Matt Turner <mattst88@gmail.com>
* i965: Rename intel_emit* to reflect their new location in brw_pipe_controlChris Wilson2015-06-241-2/+2
| | | | | Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Issue perf_debug messages for unsynchronized maps on !LLC systems.Kenneth Graunke2015-04-171-5/+11
| | | | | | | | | | | | | | | | | We haven't implemented proper unsynchronized map support on !LLC systems (pre-SNB, Atom). MapBufferRange with GL_MAP_UNSYNCHRONIZE_BIT will actually do a synchronized map, probably killing performance. Also warn on BufferSubData, when we should be doing an unsynchronized upload, but instead have to do a synchronous map. v2: Only complain if the buffer is actually busy - we use unsynchronized maps internally for vertex upload and such, but expect those to not be busy. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Tested-by: Ben Widawsky <ben@bwidawsk.net>
* i965/state: Don't use brw->state.dirty.brwJordan Justen2015-03-311-3/+3
| | | | | | | | | | | | | | | Now, we only use ctx->NewDriverState. I used this bash & sed command in the i965 directory: for file in *.[ch] *.[ch]pp; do sed -i -e 's/state\.dirty\.brw/ctx.NewDriverState/g' $file done Followed by manual changes to brw_state_upload.c. Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Kristian Høgsberg <krh@bitplanet.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Rename intel_bufferobj_* functions to match GL and DD hooks.Kenneth Graunke2014-10-291-65/+64
| | | | | | | | | | | | | | | | | | | | The GL functions and driver hooks use corresponding names---for example, glMapBufferRange and Driver.MapBufferRange. But our implementation was called "intel_bufferobj_map_range," which has the words "map" and "buffer" swapped, as well as randomly adding "obj." FlushMappedBufferRange was even trickier: it ordered the words 3, "obj", 1, 2, 4: intel_bufferobj_flush_mapped_range. Even though the old names were consistent, I always had trouble rearranging the jumble of words when searching for a function, and it took a few tries to eventually land there. The new names match the word order of GL and the driver hooks; FlushMappedBufferRange is simply brw_flush_mapped_buffer_range. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
* i965: Silence unused variable warning.Matt Turner2014-10-231-2/+1
|
* mesa: Drop the "target" parameter from NewBufferObject().Kenneth Graunke2014-10-161-2/+2
| | | | | | | | | | | NewBufferObject took a "target" parameter, which it blindly passed to _mesa_initialize_buffer_object(), which ignored it. Not much point in passing it around. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
* i965: Flag BRW_ATOMIC_COUNTER_BUFFER when a possible ABO is respecifiedChris Forbes2014-10-161-0/+2
| | | | | Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Francisco Jerez <currojerez@riseup.net>
* i965: Dirty state in BO reallocation based on usage historyChris Forbes2014-10-161-1/+4
| | | | | Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
* i965: Issue performance warnings on MapBufferRange stalls.Kenneth Graunke2014-10-131-3/+4
| | | | | | | | This is easy: we just need to use brw_map_bo instead of mapping it directly. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
* i965: Add extra null check in intel_bufferobj_alloc()Juha-Pekka Heikkila2014-09-231-0/+3
| | | | | | | Check calloc returned requested memory. Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
* Revert 5 i965 patches: 8e27a4d2, 373143ed, c5bdf9be, 6f56e142, 88e3d404Jordan Justen2014-09-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | Reverts * "i965: Modify state upload to allow 2 different sets of state atoms." 8e27a4d2b3e4e74e9a77446bce49607433d86be3 * "i965: Modify dirty bit handling to support 2 pipelines." 373143ed9187c4d4ce1e3c486b5dd0880d18ec8b * "i965: Create a macro for checking a dirty bit." c5bdf9be1eca190417998d548fd140c1eca37a54 Conflicts: src/mesa/drivers/dri/i965/brw_context.h * "i965: Create a macro for setting all dirty bits." 6f56e1424d923fd80c84090fbf4506c9eaaffea1 Conflicts: src/mesa/drivers/dri/i965/brw_blorp.cpp src/mesa/drivers/dri/i965/brw_state_cache.c src/mesa/drivers/dri/i965/brw_state_upload.c * "i965: Create a macro for setting a dirty bit." 88e3d404dad009d8cff5124cf8acee7daeaceb64 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
* i965: Create a macro for setting a dirty bit.Paul Berry2014-09-011-1/+1
| | | | | | | This will make it easier to extend dirty bit handling to support compute shaders. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* i965: Add support for GL_ARB_buffer_storage.Eric Anholt2014-03-141-2/+7
| | | | | | | | | | | | It turns out we can allow COHERENT storage/mappings all the time, regardless of LLC vs non-LLC. It just means never using temporary mappings to avoid GPU stalls, and on non-LLC we have to use the GTT intead of CPU mappings. If we were to use CPU maps on non-LLC (which might be useful if apps end up using buffer_storage on PBO reads, to avoid WC read slowness), those would be PERSISTENT but not COHERENT, but doing that would require us driving the clflushes from userspace somehow. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Always use CPU mappings for BOs on LLC platforms.Eric Anholt2014-03-141-1/+1
| | | | | | | | It looks like there's no big difference for write-only workloads, but using a CPU map means that if they happen to read without having set the MAP_READ_BIT, they get 100x the performance for those reads. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Drop the system-memory temporary allocations for flush explicit.Eric Anholt2014-03-141-51/+52
| | | | | | | While in expected usage patterns nobody will ever hit this path, doubling our bandwidth used seems like a waste, and it cost us extra code too. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Switch mapping modes for non-explicit-flush blit-temporary maps.Eric Anholt2014-03-141-3/+3
| | | | | | | | | On LLC, it should always be better to use a cached mapping than the GTT. On non-LLC, it seems pretty silly to try to optimize read performance for the INVALIDATE_RANGE_BIT case. This will make the buffer_storage logic easier. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Fix segfaults since the buffer_storage changes.Eric Anholt2014-02-251-1/+1
|
* mesa: allow buffers to be mapped multiple timesMarek Olšák2014-02-251-43/+54
| | | | | | | | | | | | | | | | | | | OpenGL allows a buffer to be mapped only once, but we also map buffers internally, e.g. in the software primitive restart fallback, for PBOs, vbo_get_minmax_index, etc. This has always been a problem, but it will be a bigger problem with persistent buffer mappings, which will prevent all Mesa functions from mapping buffers for internal purposes. This adds a driver interface to core Mesa which supports multiple buffer mappings and allows 2 mappings: one for the GL user and one for Mesa. Note that Gallium supports an unlimited number of buffer and texture mappings, so it's not really an issue for Gallium. v2: fix unmapping in xm_dd.c, remove the GL errors there v3: fix the intel driver (by Fredrik) Reviewed-by: Fredrik Höglund <fredrik@kde.org>
* mesa: add storage flags parameter to Driver.BufferDataMarek Olšák2014-02-251-1/+4
| | | | | | | It will be used by glBufferStorage. The parameters are chosen according to ARB_buffer_storage. Reviewed-by: Fredrik Höglund <fredrik@kde.org>
* i965: Stop throwing away our double precision for time calculations.Eric Anholt2014-02-211-2/+2
| | | | | | Fixes negative times being reported in our perf debug. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Create drm_intel_bo_map wrappers with performance warnings.Kenneth Graunke2014-02-031-0/+40
| | | | | | | | | | | | | | | | | | | | | | Mapping a buffer is a common place where we could stall the CPU. In a few places, we've added special code to check whether a buffer is busy and log the stall as a performance warning. Most of these give no indication of the severity of the stall, though, since measuring the time is a small hassle. This patch introduces a new brw_bo_map() function which wraps drm_intel_bo_map, but additionally measures the time stalled and reports a performance warning. If performance debugging is not enabled, it simply maps the buffer with negligable overhead. We also add a similar wrapper for drm_intel_gem_bo_map_gtt(). This should make it easy to add performance warnings in lots of places. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Carl Worth <cworth@cworth.org> Reviewed-by: Eric Anholt <eric@anholt.net>
* i965: Ensure that intel_bufferobj_map_range meets alignment guaranteesIan Romanick2014-01-201-7/+21
| | | | | | | | | | | | | | | | No piglit regressions on IVB. With minor tweaks to the arb_map_buffer_alignment-map-invalidate-range test (disable the extension check, set alignment to 64 instead of querying), the i965 driver would fail the test without this patch (as predicted by Eric). With this patch, it passes. v2: Remove MAX2(64, ...). Suggested by Ken. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net> Cc: Siavash Eliasi <siavashserver@gmail.com>
* s/Tungsten Graphics/VMware/José Fonseca2014-01-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* i965: Don't do the temporary-and-blit-copy for INVALIDATE_RANGE maps.Eric Anholt2014-01-091-1/+2
| | | | | | | | | | | | | | | | We definitely want to fall through to the unsynchronized map case, instead of wasting bandwidth on a copy. Prevents a -43.2407% +/- 1.06113% (n=49) performance regression on aa10perf when teaching glamor to provide the GL_INVALIDATE_RANGE_BIT information. This is a performance fix, which I usually wouldn't cherry-pick to stable. But this was really was just a bug in the code, its presence would discourage developers from giving us the best information they can, and I think we've got fairly high confidence in the unsynchronized map path already. Cc: 10.0 9.2 <mesa-stable@lists.freedesktop.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Drop trailing whitespace from the rest of the driver.Kenneth Graunke2013-12-051-5/+5
| | | | | | | Performed via: $ for file in *; do sed -i 's/ *//g'; done Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Try to avoid stalls on the GPU when doing glBufferSubData().Eric Anholt2013-10-231-11/+77
| | | | | | | | | | | | On DOTA2, framerate on dota2-de1.dem in windowed mode on my laptop improves by 7.69854% +/- 0.909163% (n=3). In a microbenchmark hitting this code path (wall time of piglit vbo-subdata-many), runtime decreases from 0.8 to 0.05 seconds. v2: Use out of range start/end instead of separate bool for the active flag (suggestion by Jordan), fix double-upload in the stalling path. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* i965: Add a note about the late-allocation in intel_bufferobj_buffer().Eric Anholt2013-10-231-0/+4
| | | | | | | | This was mostly for the i915 system-memory VBO code, which we don't have any more, but since that existed we've ended up producing dependencies on it being there. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* i965: Drop intel_bufferobj_source().Eric Anholt2013-10-231-13/+2
| | | | | | | Since src_offset was always 0, it wasn't doing anything for us beyond intel_bufferobj_buffer(). Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* i965: Directly call intel_batchbuffer_flush() after i915 split.Eric Anholt2013-08-301-1/+1
| | | | | | | | intel_flush() now did nothing except call through (and intel_batchbuffer_flush() does the no-op check, too!) Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Paul Berry <stereotype441@gmail.com>
* i965: Improve comments for driver hooks in intel_buffer_object.c.Kenneth Graunke2013-08-161-16/+52
| | | | | | | | | | Consistently using a "The ___ driver hook." line at the the top of each function's comment block makes it easy to see at a glance what function is being implemented. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Paul Berry <stereotype441@gmail.com>
* i965: Split intel_upload code out into a separate file.Kenneth Graunke2013-08-161-133/+0
| | | | | | | | | | This code upload performs batched uploads via a BO. By moving it out to a separate file, intel_buffer_objects.c only provides the core buffer object functionality. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Paul Berry <stereotype441@gmail.com>
* i965: Move GL_APPLE_object_purgeable functionality into a new file.Kenneth Graunke2013-08-161-136/+0
| | | | | | | | | | | | | | | | | | | | GL_APPLE_object_purgeable creates a mechanism for marking OpenGL objects as "purgeable" so they can be thrown away when system resources become scarce. It specifically applies to buffer objects, textures, and renderbuffers. The intel_buffer_objects.c file provides core functionality for GL buffer objects, such as MapBufferRange and CopyBufferSubData. Having texture and renderbuffer functionality in that file is a bit strange. The 2010 copyright on the new file is because Chris Wilson first added this code in January 2010 (commit 755915fa). v2: Actually remember to call the new dd table setup function. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Paul Berry <stereotype441@gmail.com>
* i965: Move intel_context::upload to brw_context.Kenneth Graunke2013-07-091-58/+53
| | | | | | | Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Acked-by: Chris Forbes <chrisf@ijw.co.nz> Acked-by: Paul Berry <stereotype441@gmail.com> Acked-by: Anuj Phogat <anuj.phogat@gmail.com>
* i965: Move intel_context::perf_debug to brw_context.Kenneth Graunke2013-07-091-2/+0
| | | | | | | Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Acked-by: Chris Forbes <chrisf@ijw.co.nz> Acked-by: Paul Berry <stereotype441@gmail.com> Acked-by: Anuj Phogat <anuj.phogat@gmail.com>
* i965: Move intel_context::batch to brw_context.Kenneth Graunke2013-07-091-4/+3
| | | | | | | Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Acked-by: Chris Forbes <chrisf@ijw.co.nz> Acked-by: Paul Berry <stereotype441@gmail.com> Acked-by: Anuj Phogat <anuj.phogat@gmail.com>
* i965: Move intel_context::bufmgr to brw_context.Kenneth Graunke2013-07-091-7/+5
| | | | | | | Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Acked-by: Chris Forbes <chrisf@ijw.co.nz> Acked-by: Paul Berry <stereotype441@gmail.com> Acked-by: Anuj Phogat <anuj.phogat@gmail.com>
* i965: Pass brw_context to functions rather than intel_context.Kenneth Graunke2013-07-091-33/+41
| | | | | | | | | | | | | | This makes brw_context available in every function that used intel_context. This makes it possible to start migrating fields from intel_context to brw_context. Surprisingly, this actually removes some code, as functions that use OUT_BATCH don't need to declare "intel"; they just use "brw." Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Acked-by: Chris Forbes <chrisf@ijw.co.nz> Acked-by: Paul Berry <stereotype441@gmail.com> Acked-by: Anuj Phogat <anuj.phogat@gmail.com>
* i965: Replace #include "intel_context.h" with brw_context.h.Kenneth Graunke2013-07-091-1/+1
| | | | | | | | | | | brw_context.h includes intel_context.h, but additionally makes the brw_context structure available. Switching this allows us to start using brw_context in more places. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Acked-by: Chris Forbes <chrisf@ijw.co.nz> Acked-by: Paul Berry <stereotype441@gmail.com> Acked-by: Anuj Phogat <anuj.phogat@gmail.com>
* i965: Remove intel_buffer_object::source.Kenneth Graunke2013-07-031-4/+0
| | | | | | | | | This was only used for BOs backed by system memory on i915. With that gone, there's nothing that even sets source to non-zero, so this is purely dead code. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
* i965: Fix buffer object segfault since removal of system memory BOs.Kenneth Graunke2013-07-031-0/+3
| | | | | | | | | | | | | | | | | Commit cf31a19300cbcecddb6bd0f878abb9316ebad2a1 removed support for BOs backed by system memory, as it was only useful for i915. However, it removed a little too much code: intel_bufferobj_buffer() used to call intel_bufferobj_alloc_buffer(), and after that commit, it didn't. This led to NULL pointer dereferences in several test cases, such as es3conform's transform_feedback_state_variables test. This commit restores the allocation, preserving the original behavior. It may not be the cleanest approach, but tidying should come later. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66432 Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
* i965: Drop the system-memory VBO support for i915.Eric Anholt2013-06-281-98/+4
| | | | Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Drop #ifdef I915 code.Eric Anholt2013-06-281-23/+3
| | | | Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Move the remaining intel code to the i965 directory.Eric Anholt2013-06-261-1/+853
| | | | | | | | | Now that i915's forked off, they don't need to live in a shared directory. 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)
* [intel] Merge intel_buffer_objects to shared.Eric Anholt2007-12-151-222/+1
| | | | | 965 gains fixed TTM typing of the buffer object buffers and unused PBO functions, and 915 gains buffer size == 0 fixes from 965.
generated by cgit v1.1 at 2024-05-20 12:09:11 +0000