| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
|
