aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/intel/intel_context.h
Commit message (Collapse)AuthorAgeFilesLines
* i965: Remove "single threaded" INTEL_DEBUG mode.Kenneth Graunke2011-10-251-5/+4
| | | | | | | | | | | | | | | | | According to the docs for 3DSTATE_PS (Gen7+) and 3DSTATE_WM (Gen6), there is a platform dependent value for the minimum number of pixel shader threads. It may also vary based on whether WIZ Hashing is on. For example, Ivybridge requires at least 4 threads if WIZ hashing is disabled, and 8 if it's enabled. Programming it to use less threads is illegal. Sandybridge appears to have similar restrictions. So on newer platforms, INTEL_DEBUG=sing will probably just hang the GPU. Rather than try to patch it up for newer platforms and extend it to support geometry shaders, just remove it as it isn't that useful anyway. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* intel: Add HiZ operations to intel_context::vtbl for all driversChad Versace2011-10-181-0/+16
| | | | | | | | | | | | | Add the following to the vtbl: hiz_resolve_depthbuffer hiz_resolve_hizbuffer For all drivers for which HiZ is not enabled, the methods are set to be no-ops. If HiZ is enabled, the methods are currently to set to empty stubs. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Convert from GLboolean to 'bool' from stdbool.h.Kenneth Graunke2011-10-181-23/+23
| | | | | | | | | | | | | | | | | I initially produced the patch using this bash command: for file in {intel,i915,i965}/*.{c,cpp,h}; do [ ! -h $file ] && sed -i 's/GLboolean/bool/g' $file && sed -i 's/GL_TRUE/true/g' $file && sed -i 's/GL_FALSE/false/g' $file; done Then I manually added #include <stdbool.h> to fix compilation errors, and converted a few functions back to GLboolean that were used in core Mesa's function pointer table to avoid "incompatible pointer" warnings. Finally, I cleaned up some whitespace issues introduced by the change. Signed-off-by: Kenneth Graunke <[email protected]> Acked-by: Chad Versace <[email protected]> Acked-by: Paul Berry <[email protected]>
* intel: Assert that no batch is emitted if a region is mappedChad Versace2011-10-111-0/+8
| | | | | | | | | | | | | | | | What I would prefer to assert is that, for each region that is currently mapped, no batch is emitted that uses that region's bo. However, it's much easier to implement this big hammer. Observe that this requires that the batch flush in intel_region_map() be moved to within the map_refcount guard. v2: Add comments (borrowed from anholt's reply) explaining why the assertion is a good idea. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* i965: Split brw_set_prim into brw/gen6 variantsChad Versace2011-10-101-1/+1
| | | | | | | | | | | The "slight optimization to avoid the GS program" in brw_set_prim() is not used by Gen 6, since Gen 6 doesn't use a GS program. Also, Gen 6 doesn't use reduced primitives. Also, document that intel_context.reduced_primitive is only used for Gen < 6 Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Introduce a new intel_context::gt field to go along with gen.Kenneth Graunke2011-09-261-0/+1
| | | | | | | | | | It seems that GT1/GT2 sorts of variations are here to stay, and more special cases will likely be required in the future. Checking by PCI ID via the IS_xxx_GTx macros is cumbersome; introducing a new 'gt' field analogous to intel->gen will make this easier. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* intel: Remove intel_context::has_xrgb_textures/has_luminance_srgb.Kenneth Graunke2011-09-261-2/+0
| | | | | | | | | | | | | Seeing as they were only used once (in the same function they were defined), having them as context members seemed rather pointless. Remove them entirely (rather than using local variables) since the chipset generation checks are actually just as straightforward. While we're at it, clean up the remainder of the if-tree that set them. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i915: Simplify intel_wpos_* with a helper function.Eric Anholt2011-07-181-1/+0
|
* intel: Move intel_draw_buffers() code into each driver.Eric Anholt2011-07-181-0/+1
| | | | | | | | The illusion of shared code here wasn't fooling anybody. It was tempting to keep i830 and i915 still shared, but I think I actually want to make them diverge shortly. Reviewed-by: Chad Versace <[email protected]>
* i915: Fix map/unmap mismatches from leaving INTEL_FALLBACK during TNL.Eric Anholt2011-07-121-0/+1
| | | | | | | | | | | | | The first rendering after context create didn't know of the color buffer yet, triggering a sw fallback. The intel_prepare_render() from intelSpanRenderStart then found the buffer and turned off fallbacks, but intelSpanRenderFinish was never called and things were left mapped. By checking buffers before making the call on whether to do the fallback pipeline or not, we avoid the fallback change inside of the rendering pipeline. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31561 Reviewed-by: Ian Romanick <[email protected]>
* i965/gen6: Limit the workaround flush to once per primitive.Eric Anholt2011-06-201-0/+2
| | | | | We're about to call this function in a bunch of state emits, so let's not spam the hardware with flushes too hard.
* i965/gen6: Use an BO instead of writing to address 0 for PIPE_CONTROL W/A.Eric Anholt2011-06-201-1/+2
| | | | | | | | This was spectacularly unsafe. On my system, address 0 happens to be the hardware status page for the render ring, and the first quadword of that happens to contain nothing we ever look at, but I sure didn't look forward to having to debug some day when, for example, the kernel happened to bind the ringbuffer before binding the hwsp.
* intel: Implement glFinish() correctly by waiting on all previous rendering.Eric Anholt2011-06-071-0/+4
| | | | | Before, we were waiting for (most of) the current framebuffer to be done, which is not quite the same thing.
* intel: Add is_hiz_depth_format() to intel_contex.vtblChad Versace2011-05-251-0/+4
| | | | | | | | | Given a format, is_hiz_depth_format() indicates if HiZ can be enabled on a depthbuffer of that format. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Add flags to intel_context for hiz and separate stencilChad Versace2011-05-251-0/+3
| | | | | | | | | | | | | | | | | | | Add the following flags: intel_context.has_separate_stencil intel_context.must_use_separate_stencil intel_context.has_hiz The flags are currently set to false, and will be enabled for a given chipset once the feature is completely implemented. Since it may be some time before these features are completed, their values can be overridden with environment variables INTEL_HIZ and INTEL_SEPARATE_STENCIL. Valid values for these environment variables are "0" and "1". Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* Revert "intel: use throttle ioctl for throttling"Eric Anholt2011-04-271-0/+1
| | | | | | | | | | | | | This reverts commit 50ade6ea697953bb17e3ca7210515fbd0411cd1e. Fixes jerky rendering again on apps that don't block on the GPU per frame and are GPU bound (e.g. 3DMMES on Ironlake). The whole point of this complicated throttle scheme is to wait on frame n-1 to have started rendering before starting frame n's rendering. Otherwise, the GPU-bound app will race ahead and call the GL to draw many nearly-identical frames, then >0ms later get stuck waiting for them (all dispatched at about the same time) to retire, then render a new batch of nearly-identical frames.
* intel: Fix ROUND_DOWN_TO macroIan Romanick2011-04-111-3/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously the macro would (ALIGN(value - alignment - 1, alignment)). At the very least, this was missing parenthesis around "alignment - 1". As a result, if value was already aligned, it would be reduced by alignment. Condisder: x = ROUND_DOWN_TO(256, 128); This becomes: x = ALIGN(256 - 128 - 1, 128); Or: x = ALIGN(127, 128); Which becomes: x = 128; This macro is currently only used in brw_state_batch (brw_state_batch.c). It looks like the original version of this macro would just use too much space in the batch buffer. It's possible, but not at all clear to me from the code, that the original behavior is actually desired. In any case, this patch does not cause any piglit regressions on my Ironlake system. I also think that ALIGN_FLOOR would be a better name for this macro, but ROUND_DOWN_TO matches rounddown in the Linux kernel. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Keith Whitwell <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Fix insufficient integer width for upload buffer offsetChris Wilson2011-02-211-2/+2
| | | | | | | | I was being overly miserly and gave the offset of the buffer into the bo insufficient bits, distracted by the adjacency of the buffer[4096]. Ref: https://bugs.freedesktop.org/show_bug.cgi?id=34541 Signed-off-by: Chris Wilson <[email protected]>
* intel: use throttle ioctl for throttlingChris Wilson2011-02-211-1/+0
| | | | | | | | | | Rather than waiting on the first batch after the last swapbuffers to be retired, call into the kernel to wait upon the retirement of any request less than 20ms old. This has the twofold advantage of (a) not blocking any other clients from utilizing the device whilst we wait and (b) we attain higher throughput without overloading the system. Signed-off-by: Chris Wilson <[email protected]>
* i965: Move repeat-instruction-suppression to batchbuffer coreChris Wilson2011-02-211-11/+3
| | | | | | | | Move the tracking of the last emitted instructions into the core batchbuffer routines and take advantage of the shadow batch copy to avoid extra memory allocations and copies. Signed-off-by: Chris Wilson <[email protected]>
* intel: use pwrite for batchChris Wilson2011-02-211-2/+22
| | | | | | | | | | | It's faster. Not only is the memcpy more efficiently performed in the kernel (making up for the system call overhead), but by not using mmap we remove the greater overhead of tracking the vma of every batch. And it means we can read back from the batch buffer without incurring the cost of a uncached read through the GTT. Signed-off-by: Chris Wilson <[email protected]>
* intel: Buffered uploadChris Wilson2011-02-211-0/+3
| | | | | | | | | Rather than performing lots of little writes to update the common bo upon each update, write those into a static buffer and flush that when full (or at the end of the batch). Doing so gives a dramatic performance improvement over and above using mmaped access. Signed-off-by: Chris Wilson <[email protected]>
* intel: Pack dynamic draws togetherChris Wilson2011-02-211-0/+5
| | | | | | | | Dynamic arrays have the tendency to be small and so allocating a bo for each one is overkill and we can exploit many efficiency gains by packing them together. Signed-off-by: Chris Wilson <[email protected]>
* intel: Remove setup of the old dri/ meta code, which is now unused.Eric Anholt2011-02-121-3/+0
|
* intel: Add a vtbl hook for determining if a format is renderable.Eric Anholt2011-01-071-0/+1
| | | | | | | By relying on just intel_span_supports_format, some formats that aren't supported pre-gen4 were not reporting FBO incomplete. And we also complained in stderr when it happened on i915 because draw_region gets called before framebuffer completeness validation.
* intel: Include stdbool so we can stop using GLboolean when we want to.Eric Anholt2010-12-131-1/+1
| | | | | This requires shuffling the driconf XML macros around, since they use true and false tokens expecting them to not get expanded to anything.
* i965: Remove INTEL_DEBUG=glsl_force now that there's no brw_wm_glsl.cEric Anholt2010-12-061-1/+0
|
* intel: Add an env var override to execute for a different GPU revision.Eric Anholt2010-12-041-1/+0
| | | | | | | Sometimes I'm on the train and want to just read what's generated under INTEL_DEBUG=vs,wm for some code on another generation. Or, for the next gen enablement we'll want to dump aub files before we have the actual hardware. This will let us do that.
* intel: Remove leftover dri1 locking fields in the context.Eric Anholt2010-11-031-3/+0
|
* intel: Annotate debug printout checks with unlikely().Eric Anholt2010-11-031-1/+16
| | | | | | | This provides the optimizer with hints about code hotness, which we're quite certain about for debug printouts (or, rather, while we developers often hit the checks for debug printouts, we don't care about performance while doing so).
* Drop GLcontext typedef and use struct gl_context insteadKristian Høgsberg2010-10-131-6/+6
|
* Rename GLvisual and __GLcontextModes to struct gl_configKristian Høgsberg2010-10-131-1/+1
|
* i965: Apply the rest of the old-libdrm guard patch.Cedric Vivier2010-08-301-0/+13
| | | | Bug #29855
* intel: Remove include of texmem.h, since we haven't used it in ages.Eric Anholt2010-08-131-1/+0
|
* i965: Add support for streaming indirect state rather than caching objects.Eric Anholt2010-06-111-0/+2
|
* intel: Change dri_bo_* to drm_intel_bo* to consistently use new API.Eric Anholt2010-06-081-1/+1
| | | | | The slightly less mechanical change of converting the emit_reloc calls will follow.
* i915: Don't use XRGB8888 on 830 and 845.Eric Anholt2010-06-041-0/+1
| | | | | | | | | The support for XRGB8888 appeared in the 855 and 865, and this format is reserved on 830/845. This should fix a regression from b4a6169412819cc3a027c6a118f0537911145a30 that caused hangs in etracer on 845s. Bug #26557.
* intel: Throttle after doing copyregion/swapbuffers round tripKristian Høgsberg2010-05-201-1/+1
| | | | | | | | | | | 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.
* i965: Add SF program disasm under INTEL_DEBUG=sf.Eric Anholt2010-05-171-1/+1
|
* i965: Add program dumping for INTEL_DEBUG=gs.Eric Anholt2010-05-141-1/+1
|
* i965: Support INTEL_DEBUG=clip to dump the clip program.Eric Anholt2010-05-141-0/+1
|
* intel: Drop viewport hack when we canKristian Høgsberg2010-05-111-3/+2
|
* intel: Drop intelFlush()Kristian Høgsberg2010-05-101-2/+1
| | | | | Now that intel_flush() deosn't use the needs_mi_flush argument, we can finally drop one of the two flush functions.
* dri: Add DRI entrypoints to create a context for a given APIKristian Høgsberg2010-04-281-0/+1
|
* intel: Clean up chipset name and gen num for IronlakeZhenyu Wang2010-04-211-1/+0
| | | | | | | | | Rename old IGDNG to Ironlake, and set 'gen' number for Ironlake as 5, so tracking the features with generation num instead of special is_ironlake flag. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]>
* intel: Remove redundant fields from struct intel_contextKristian Høgsberg2010-03-301-3/+0
| | | | All these pointers are in the __DRIcontext struct, which we point to.
* i965: Add INTEL_DEBUG=glsl_force to force brw_wm_glsl.c.Eric Anholt2010-03-221-0/+1
| | | | | I keep finding the desire to force this path to debug it instead of cooking up goofy-looking testcases to do so.
* intel: Remove non-kernel-exec-fencing support.Eric Anholt2010-03-041-21/+0
| | | | | | | Shaves 60k off the driver from removing the broken spans code. This means we now require 2.6.29, which seems fair given that it's a year old and we've removed support for non-KMS already in the last release of 2D.
* Replace the _mesa_*printf() wrappers with the plain libc versionsKristian Høgsberg2010-02-191-1/+1
|
* intel: Implement the DRI2 invalidate function properlyKristian Høgsberg2010-02-171-0/+1
| | | | | | | | | | | | | | | | | | | This uses a stamp mechanisms to mark the DRI drawable as invalid. Instead of immediately updating the buffers we just bump the drawable stamp and call out to DRI2GetBuffers "later". "Later" used to be at LOCK_HARDWARE time, and this patch brings back callouts at the points where we used to call LOCK_HARDWARE. A new function, intel_prepare_render(), is called where we used to call LOCK_HARDWARE, and if the buffers are invalid, we call out to DRI2GetBuffers there. This lets us invalidate buffers only when notified instead of on every glViewport() call. If the loader calls the DRI invalidate entrypoint, we disable viewport triggered buffer invalidation. Additionally, we can clean up the old viewport mechanism a bit, since we can just invalidate the buffers and not worry about reentrancy and whatnot.