| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
v2: Remove it from i915, too (change by anholt)
Acked-by: Eric Anholt <[email protected]>
|
| |
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
|
| |
While i915 does have hardware contexts in hardware, we don't expect there
to ever be SW support for it (given that support hasn't even made it back
to gen5 or gen4).
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
| |
This was formerly-shared code for supporting gen5+.
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
| |
This hardware doesn't have MSAA support, so this code is all a waste for it.
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
| |
v2: Remove extra struct forward declaration (change by Ken)
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
The fix for pageflipping with cliprects ended up causing a batch flush at
an inopportune time, which is fixed by moving it up.
Additionally, the recovery code for handling batch wraps at bad times is
replaced by just checking for the space up front, and using a no_batch_wrap
assert like on 965 to make sure that we weren't wrong about how much space that
was.
|
| |
|
|
|
|
|
| |
Both drivers have ended up relying on lost_hardware being called after each
batch buffer, so update the name. This removes one of the calls on 965 whic
h was outside of the batchbuffer handling code and just duplicating what had
already happened through batchbuffer handling.
|
| |
|
|
| |
fix #11925
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is currently believed to work but be a significant performance loss.
Performance recovery should be soon to follow.
The dri_bo_fake_disable_backing_store() call was added to allow backing store
disable like bufmgr_fake.c did, which is a significant performance win (though
it's missing the no-fence-subdata part).
This commit is a squash merge of the 965-ttm branch, which had some history
I wanted to avoid pulling due to noisiness and brokenness at many points
for git-bisecting.
|
| |
|
|
| |
This could lead to incorrect rendering or even lockups.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This was replaced in previous releases of xserver/dri/libGL by reporting the
damage to the frontbuffer so that the server and driver could handle it
appropriately.
|
| |
|
|
|
|
|
|
| |
In the process, fix some alignment issues:
- Scratch space allocation was aligned into units of 1KB, while the allocation
wanted units of bytes, so we never allocated enough space for scratch.
- GRF register count was programmed as ALIGN(val - 1, 16) / 16 instead of
ALIGN(val, 16) / 16 - 1, which overcounted for val != 16n+1.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
(untested)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This has some advantages over the traditional way of first waiting for the
target vertical blank and then emitting the buffer swap, e.g.
* glXSwapBuffers returns immediately, only the next time the driver needs the
hardware lock will it block until the target vertical blank. This should
allow applications that don't intermix rendering and other processing to
start processing for the next frame right away.
* It's less likely to produce tearing.
|
| |
|
|
| |
Cleanup invarient state emission.
|
| | |
|
| | |
|
| |
|
|
|
| |
Add rotation support
(Tungsten Graphics)
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* GL_ARB_texture_cube_map
* GL_EXT_blend_equation_separate
* GL_ATI_blend_equation_separate
* GL_ARB_point_parameters
* GL_NV_blend_square
* GL_EXT_cull_vertex
* GL_ARB_depth_texture
* GL_SGIX_depth_texture
* GL_ARB_shadow
* GL_EXT_shadow_funcs
* GL_3DFX_texture_compression_FXT1
(Keith Whitwell, Tungsten Graphics)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(patented) S3TC/DXTC algorithms, but adds an option to dlopen a library module
providing functions to do so. Because it uses dlopen, it is only enabled if
USE_EXTERNAL_DXTN_LIB=1 is defined (which is only in linux-dri config, so far).
It adds support for S3TC to several DRI drivers, and adds a DRI config option to
force enabling S3TC even if the software compression/decompression is
unavailable. This may allow people to use apps that require S3TC even though
they don't have a license to implement the patented material themselves, if
those apps use precompressed textures.
Ideally we would get permission from the current holder of the patents to
implement the algorithm in Mesa, at which point the dlopen mess could go away.
Until then, this allows some to run applications they couldn't otherwise, and
hopefully will provide us with more push to get the final step of getting that
permission done.
|
| | |
|
| | |
|
| |
|
