aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/i915/intel_context.c
Commit message (Collapse)AuthorAgeFilesLines
* i915: Check return value of screen->image.loader->getBuffersEmil Velikov2016-08-301-6/+9
| | | | | | | | | Ported from the i965 commit e7ab358e8186dd8651cf920d4db1500c60ccd2fc. Cc: 11.2 12.0 <[email protected]> Cc: Tomasz Figa <[email protected]> Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* i915: correctly parse/set the context flagsEmil Velikov2016-01-221-0/+2
| | | | | | | | | | | | | | | | | With an earlier commit we've spit the flags parsing to a separate function, but forgot to update all the dri modules to use it. Noticed when we've enabled KHR_debug for every dri module - fdo#93048 Fixes: 38366c0c6e7 "dri_util: Don't assume __DRIcontext->driverPrivate is a gl_context" Cc: Mark Janes <[email protected]> Cc: "11.0 11.1" <[email protected]> Cc: Kristian Høgsberg <[email protected]> Cc: Ian Romanick <[email protected]> Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Mark Janes <[email protected]> Tested-by: Mark Janes <[email protected]>
* util: Move DRI parse_debug_string() to utilKristian Høgsberg Kristensen2015-10-081-2/+3
| | | | | | | | | | We want to use intel_debug.c in code that doesn't link to dri common. v2: Remove unnecessary stddef.h include (Topi), use util/debug.h in all DRI driver and remove driParseDebugString() (Iago). Reviewed-by: Topi Pohjolainen <[email protected]> Signed-off-by: Kristian Høgsberg Kristensen <[email protected]>
* i915: Drop broken front_buffer_reading/drawing optimizationVille Syrjälä2015-10-061-5/+7
| | | | | | | | | | | | | | | | | | | | | Bring the following commit over to i915: commit ec542d74578bbef6b55125dd6aba1dc7f5079e65 Author: Eric Anholt <[email protected]> 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ä <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i915: Adjust line size limitsVille Syrjälä2015-10-061-2/+2
| | | | | | | | | | | | The hardware can draw lines 0.5 to 7.5 pixels wide. Adjust the limits to 1.0-7.0. The old limits seems to be from the era when i915 and i965 were sharing this code. Not really sure if 1.0-7.0 is correct. Maybe it could be 0.5.7.5 as those are the hw limits, or maybe some combination of the two? Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i915: remove unused driFd variableEmil Velikov2015-07-131-1/+0
| | | | | Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i915: replace __FUNCTION__ with __func__Marius Predut2015-04-141-1/+1
| | | | | | | | Consistently just use C99's __func__ everywhere. No functional changes. Acked-by: Matt Turner <[email protected]> Signed-off-by: Marius Predut <[email protected]>
* i915: Kill intel_context::hw_stencilVille Syrjälä2014-11-131-1/+0
| | | | | | | ctx.hw_stencil is not used anywhere so kill it. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]>
* util: Move ralloc to a new src/util directory.Kenneth Graunke2014-08-041-1/+1
| | | | | | | | | | | | | | | | | | For a long time, we've wanted a place to put utility code which isn't directly tied to Mesa or Gallium internals. This patch creates a new src/util directory for exactly that purpose, and builds the contents as libmesautil.la. ralloc seemed like a good first candidate. These days, it's directly used by mesa/main, i965, i915, and r300g, so keeping it in src/glsl didn't make much sense. Signed-off-by: Kenneth Graunke <[email protected]> v2 (Jason Ekstrand): More realloc uses and some scons fixes Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* i915: add a missing NULL pointer checkLubomir Rintel2014-05-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | mesaVisual can be NULL with configless context since this commit: commit 551d459af421a2eb937e9e16301bb64da4624f89 Author: Neil Roberts <[email protected]> Date: Fri Mar 7 18:05:47 2014 +0000 Add the EGL_MESA_configless_context extension ... Previously the i965 and i915 drivers were explicitly creating a zeroed visual whenever 0 is passed for the EGLConfig. We attempt to dereference the visual in i915 and now we don't create a zeroed-out one one it crashes, breaking at least weston in an i915. There's no point in doing so as it would be zero anyway. v2: Fixed a typo in commit message. Added some tags. Signed-off-by: Lubomir Rintel <[email protected]> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1100967 Cc: "10.2" <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* Add the EGL_MESA_configless_context extensionNeil Roberts2014-03-121-6/+0
| | | | | | | | | | | | | | | | | | | | This extension provides a way for an application to render to multiple surfaces with different buffer formats without having to use multiple contexts. An EGLContext can be created without an EGLConfig by passing EGL_NO_CONFIG_MESA. In that case there are no restrictions on the surfaces that can be used with the context apart from that they must be using the same EGLDisplay. _mesa_initialze_context can now take a NULL gl_config which will mark the context as ‘configless’. It will memset the visual to zero in that case. Previously the i965 and i915 drivers were explicitly creating a zeroed visual whenever 0 is passed for the EGLConfig. Mesa needs to be aware that the context is configless because it affects the initial value to use for glDrawBuffer. The first time the context is bound it will set the initial value for configless contexts depending on whether the framebuffer used is double-buffered. Reviewed-by: Kristian Høgsberg <[email protected]>
* 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/[email protected]/[email protected]/ s/[email protected]/[email protected]/g s/jrfonseca-at-tungstengraphics-dot-com/jfonseca-at-vmware-dot-com/ s/jrfonseca\[email protected]/[email protected]/g s/keithw\[email protected]/[email protected]/g s/[email protected]/[email protected]/g s/thomas-at-tungstengraphics-dot-com/thellstom-at-vmware-dot-com/ s/[email protected]/[email protected]/ # 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 <[email protected]>
* mesa: Eliminate parameters to dd_function_table::ViewportIan Romanick2014-01-151-13/+2
| | | | | | | No driver uses them. They will just be annoying in future patches. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* dri_util: Don't assume __DRIcontext->driverPrivate is a gl_contextKristian Høgsberg2013-12-131-0/+1
| | | | | | | | | | | | | | | | | The driverPrivate pointer is opaque to the driver and we can't assume it's a struct gl_context in dri_util.c. Instead provide a helper function to set the struct gl_context flags from the incoming DRI context flags. v2 (idr): Modify the other classic drivers to also use driContextSetFlags. I ran all the piglit GLX_ARB_create_context tests with i965 and classic swrast without regressions. Signed-off-by: Kristian Høgsberg <[email protected]> Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Ian Romanick <[email protected]> [v1] Reviewed-by: Eric Anholt <[email protected]> Tested-by: Ilia Mirkin <[email protected]> [v1 on Gallium nouveau] Cc: "10.0" <[email protected]>
* dri: add __DRIimageLoaderExtension and __DRIimageDriverExtensionKeith Packard2013-11-071-4/+109
| | | | | | | | | | | | | | | | | | | | | These provide an interface between the driver and the loader to allocate color buffers through the DRIimage extension interface rather than through a loader-specific extension (as is used by DRI2, for instance). The driver uses the loader 'getBuffers' interface to allocate color buffers. The loader uses the createNewScreen2, createNewDrawable, createNewContext, getAPIMask and createContextAttribs APIS (mostly shared with DRI2). This interface will work with the DRI3 loader, and should also work with GBM and other loaders so that drivers need not be customized for each new loader interface, as long as they provide this image interface. v2: Fix build of i915 and i965 together (by anholt) Signed-off-by: Keith Packard <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* dri/intel: Split out DRI2 buffer update code to separate functionKeith Packard2013-11-071-41/+49
| | | | | | | | Make an easy place to splice in a DRI3 version of this function Signed-off-by: Keith Packard <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i915: Refactor the renderer string creation out of intelGetStringIan Romanick2013-11-071-13/+21
| | | | | | | | This will soon be used in intel_screen.c from a function that doesn't have a gl_context. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i915: Refactor the vendor string out of intelGetStringIan Romanick2013-11-071-2/+2
| | | | | | | | | | This will soon be used in intel_screen.c from a function that doesn't have a gl_context. v2: Remove spurious break after return. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i915: Bring sanity to the Viewport functionIan Romanick2013-11-051-6/+22
| | | | | | | | | | | The i830 and the i915 driver have the same dd_function_table::Viewport function... it just has two names and lives in two places. Using a single implementation allows cleaning up the saved_viewport nonsense too. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Cc: Courtney Goeltzenleuchter <[email protected]>
* i915: Build the driver into the shared mesa_dri_drivers.so.Eric Anholt2013-10-241-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | i915 has symbols for formerly-shared code that conflict with i965, so we define them away using gen-symbol-redefs.py. Options considered: - This option. Downsides: The symbols in profiling and debugging don't match the source. The symbol list may change in the future and we won't notice without manually running the tool again. - Use objcopy --localize-hidden to automatically demote our symbols to locals. This didn't work on i965 due to c++ weak symbols (which can't be localized), but could work on i915. We could do it on i915 only, but it does produce libtool warnings at link time due to libtool not knowing if the resulting .o file is safe to link (stupid libtool). Plus you end up with different symbols of the same name, which is confusing for debugging too. On the other hand, no future symbol conflicts long term. - Write our own libelf tool that handles c++ weak symbols like we want and apply it to all drivers. All the downsides of above, but applies uniformly across drivers. - Edit the files to just rename all the i915 or i965 symbols that conflict. There are on the order of 100 that have a prefix we used to share, so it would take a bit of typing. Fewest downsides, but still can have conflicts long term. Ultimately, this is the least invasive change at the moment, and we can see if the "more symbol conflicts appear later" thing is a real concern or not. Note that the ability to compile a version of i915 without INTEL_DEBUG env support is dropped. It's too useful. v2: drop dridir now that it's unused. v3: Consistently put spaces around += in the updated Makefile.am block. v4: Set a global driverAPI variable so loaders don't have to update to createNewScreen2() (though they may want to for thread safety). Reviewed-by: Matt Turner <[email protected]> (v2) Reviewed-by: Emil Velikov <[email protected]>
* intel: Remove silly check for !bufmgr.Eric Anholt2013-10-101-6/+0
| | | | | | | | If bufmgr didn't get created, then screen creation failed, and we never should have got here in the first place. This was added by Chris Wilson in 2010 with no explanation for why it would be needed. Reviewed-by: Kenneth Graunke <[email protected]>
* dri: Move API version validation into dri/common.Eric Anholt2013-10-101-44/+0
| | | | | | | | | | | | | | | | | i965, i915, radeon, r200, swrast, and nouveau were mostly trying to do the same logic, except where they failed to. Notably, swrast had code that appeared to try to enable GLES1/2 but forgot to set api_mask (thus preventing any gles context from being created), and the non-intel drivers didn't support MESA_GL_VERSION_OVERRIDE. nouveau still relies on _mesa_compute_version(), because I don't know what its limits actually are, and gallium drivers don't declare limits up front at all. I think I've heard talk about doing so, though. v2: Compat max version should be 30 (noted by Ken) Drop r100's custom max version check, too (noted by Emil Velikov) Reviewed-by: Kenneth Graunke <[email protected]>
* i915: Remove i965+ chip names.Kenneth Graunke2013-07-091-1/+0
| | | | | | | | | i965+ chipsets shouldn't ever hit this driver. Signed-off-by: Kenneth Graunke <[email protected]> Acked-by: Chris Forbes <[email protected]> Acked-by: Paul Berry <[email protected]> Acked-by: Anuj Phogat <[email protected]>
* i915: Remove GLES 3.0 sRGB workaround.Kenneth Graunke2013-06-281-52/+0
| | | | | | Gen3 doesn't support GLES 3.0, so there's no need for it. Acked-by: Eric Anholt <[email protected]>
* i915: Remove dead debug flags.Eric Anholt2013-06-281-10/+0
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i915: Drop context fields specific to 965+ chipsets.Eric Anholt2013-06-281-19/+2
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i915: Drop all has_llc code.Eric Anholt2013-06-281-1/+0
| | | | | | i915 never has llc. Reviewed-by: Kenneth Graunke <[email protected]>
* i915: Remove most of the code under gen >= 4 checks.Eric Anholt2013-06-281-35/+5
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i915: Remove separate stencil code.Eric Anholt2013-06-281-2/+0
| | | | | | This was formerly-shared code for supporting gen5+. Reviewed-by: Kenneth Graunke <[email protected]>
* i915: Remove the I915 macro from the formerly shared code.Eric Anholt2013-06-281-2/+0
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i915: Remove all the MSAA support code.Eric Anholt2013-06-281-58/+4
| | | | | | This hardware doesn't have MSAA support, so this code is all a waste for it. Reviewed-by: Kenneth Graunke <[email protected]>
* i915: Remove all the HiZ code from i915.Eric Anholt2013-06-281-8/+0
| | | | | | v2: Remove extra struct forward declaration (change by Ken) Reviewed-by: Kenneth Graunke <[email protected]>
* i915: Fork the shared code from i965.Eric Anholt2013-06-261-1/+1010
| | | | | | | | | | | | | 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 <[email protected]> Acked-by: Chad Versace <[email protected]> Acked-by: Adam Jackson <[email protected]> (and I hear second hand that idr is OK with it, too)
* Merge {i915,i965}/intel_context.h as intel/intel_context.hKristian Høgsberg2008-02-221-862/+1
|
* Use drm_i915_sarea instead of drmI830Sarea and remove i830_common.hAlan Hourihane2008-02-221-2/+2
|
* Add E7221 variant to i915.Adam Jackson2008-02-151-0/+4
|
* Hook up i915 driver to new DRI2 infrastructure.Kristian Høgsberg2008-02-141-32/+43
|
* [intel] Fix 965 rendering with non-TTM by merging intel_ioctl between 915/965.Eric Anholt2008-02-131-0/+5
| | | | | | The 965 path wasn't setting pClipRects for batch submission since it didn't want kernel cliprect handling before. The 915 path also grew the INTEL_NO_HW=1 option for testing just driver overhead.
* [intel] Make the no_rast option be standard driconf instead of INTEL_NO_RAST.Eric Anholt2008-01-171-1/+1
|
* [i915] Fix recursive lock hang in intelContendedLock handling.Eric Anholt2008-01-141-2/+2
|
* [intel] Add more cliprect modes to cover other meanings for batch emits.Eric Anholt2008-01-101-1/+7
| | | | | | | | | | | | | | | The previous change gave us only two modes, one which looped over the batch per cliprect (3d drawing) and one that didn't (state updeast). However, we really want 4: - Batch doesn't care about cliprects (state updates) - Batch needs DRAWING_RECTANGLE looping per cliprect (3d drawing) - Batch needs to be executed just once (region fills, copies, etc.) - Batch already includes cliprect handling, and must be flushed by unlock time (copybuffers, clears). All callers should now be fixed to use one of these states for any batchbuffer emits. Thanks to Keith Whitwell for pointing out the failure.
* [intel] Simplify intelCreateBuffer() a bit.Kristian Høgsberg2008-01-091-13/+13
| | | | | | Drop a bunch of unused arguments from intel_create_renderbuffer() and introduce intel_renderbuffer_set_region() to set the region for a renderbuffer.
* Replace gl_framebuffer's _ColorDrawBufferMask with _ColorDrawBufferIndexesBrian2008-01-061-3/+1
| | | | | | | Each array element is now a BUFFER_x token rather than a BUFFER_BIT_x bitmask. The number of active color buffers is specified by _NumColorDrawBuffers. This builds on the previous DrawBuffer changes and will help with drivers implementing GL_ARB_draw_buffers.
* fix fd.o bug #13761Zou Nan hai2008-01-031-2/+2
| | | | MRD computation is now changed in mesa core
* [intel] Fix and reenable (software) SGIS_generate_mipmapEric Anholt2007-12-201-1/+1
| | | | | | | The core problem was that _mesa_generate_mipmap was not respecting RowStride of the source image. Additionally, the intel private data associated with the images (level and face) was not being initialized for the _mesa_generate_mipmap-generated images.
* [915] Free dri_bufmgr after mesa context data.Eric Anholt2007-12-181-2/+2
| | | | Fixes a crash when buffer objects are left around until context destroy.
* [intel] Enable INTEL_DEBUG=bufmgr output in TTM mode as well as classic.Eric Anholt2007-12-131-2/+2
|
* [intel] Move bufmgr back to context instead of screen, fixing glthreads.Eric Anholt2007-12-121-17/+101
| | | | | | | | Putting the bufmgr in the screen is not thread-safe since the emit_reloc changes. It also led to a significant performance hit from pthread usage for the attempted thread-safety (up to 12% of a cpu spent on refcounting protection in single-threaded 965). The motivation had been to allow multi-context bufmgr sharing in classic mode, but it wasn't worth the cost.
* [i915] Make INTEL_DEBUG=bufmgr actually do things for bufmgr_fake.Eric Anholt2007-11-291-0/+2
|
* [i915] Add INTEL_DEBUG=sync debug flag to wait for fences after making them.Eric Anholt2007-11-161-0/+1
|