| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Fixes regression: https://bugs.freedesktop.org/show_bug.cgi?id=34160
Commit e7c1f058d18f62aa4871aec623f994d7b68cb8c1 disabled constant-folding
when division-by-zero occured. This was a mistake, because the spec does
allow division by zero. (From section 5.9 of the GLSL 1.20 spec: Dividing
by zero does not cause an exception but does result in an unspecified
value.)
For floating-point division, the original pre-e7c1f05 behavior is
reinstated.
For integer division, constant-fold 1/0 to 0.
|
|
This reverts commit b3cf92aa916ee0537ee37723c23a9897ac9cd3e0.
The reverted commit prevented constant-folding of reciprocal expressions
when the reciprocated expression was 0. However, since the spec allows
division by zero, constant-folding *is* permissible in this case.
From Section 5.9 of the GLSL 1.20 spec:
Dividing by zero does not cause an exception but does result in an
unspecified value.
|
|
Before populating the vertex buffer attribute pointer (VB->AttribPtr[]),
convert vertex data in GL_FIXED format to GL_FLOAT.
Fixes bug: http://bugs.freedesktop.org/show_bug.cgi?id=34047
NOTE: This is a candidate for the 7.9 and 7.10 branches.
|
|
|
|
And set a reasonable buffer usage flag everywhere instead of
just PIPE_USAGE_DEFAULT.
|
|
|
|
I typod this when copy-pasting.
|
|
Fixes this GCC warning.
nvc0_tgsi_to_nc.c: In function 'bld_tex':
nvc0_tgsi_to_nc.c:1392: warning: 'dim' may be used uninitialized in this function
|
|
This is a multi-threading optimization which hides the kernel overhead
behind a thread. It improves performance in CPU-limited apps by 2-15%.
Of course you must have at least 2 cores for it to make any difference.
It can be disabled with:
export RADEON_THREAD=0
|
|
On r600, s3tc formats require a 1D tiled texture format,
so we have to do uploads using a blit, via the 64-bit and 128-bit formats
Based on the r600c code we use a 64 and 128-bit type to do the
blits.
Still requires R600_ENABLE_S3TC until the kernel fixes are in,
this has only been tested on evergreen where the kernel doesn't
yet get in the way.
|
|
the miptree setup and pitch storing didn't work so well for block
based things like compressed textures. The CB takes blocks, where
the texture sampler takes pixels, and transfers need bytes,
So now we store blocks/bytes and translate to pixels in the sampler.
This is necessary for s3tc to work properly.
|
|
we can work this out from the array_mode and it makes more sense
to do that.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
If the underlying transfer had a stride wider for hw alignment reasons,
the mipmap generation would generate badly strided images.
this fixes a few problems I found while testing r600g with s3tc
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Broken since d5062fb3a315c46d77d5c954a3e3c14be1907d33.
I wonder why this code is hidden behind #if by default.
|
|
Ooops.
|
|
The VBO module uses both, but they are somewhat opposite to each other.
In this case, we pick UNSYNCHRONIZED and ignore DONTBLOCK.
|
|
This is the last one I think.
|
|
So finally we have them.
|
|
|
|
|
|
The winsys takes care of flushing automatically.
|
|
Because an app may do something like this:
while (!(ptr = bo_map(..., DONT_BLOCK))) {
/* Do some other work. */
}
And it would be looping endlessly if we didn't flush.
|
|
This is a follow-up to commit cdca3c58aa2d9549f5188910e2a77b438516714f.
|
|
This is a follow-up to commit cdca3c58aa2d9549f5188910e2a77b438516714f.
|
|
render targets if ARB_draw_buffers_blend is not supported
If EXT_draw_buffers2 is supported but ARB_draw_buffers_blend isn't
_mesa_BlendFuncSeparateEXT only sets up the blend equation and function for the
first render target. This patch makes sure that update_blend doesn't try to use
the data from other rendertargets in such cases.
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
|
|
This is cleaner and implementing the hook is optional.
|
|
Also implement the redefine_user_buffer hook in the drivers.
|
|
The vertex arrays state should be set only when (_NEW_ARRAY | _NEW_PROGRAM)
is dirty. This assumes user buffer content is mutable, which will be
sorted out in the next commit. The following usage case should be much faster
now:
for (i = 0; i < 1000; i++) {
glDrawElements(...);
}
Or even:
for (i = 0; i < 1000; i++) {
glSomeStateChangeOtherThanArraysOrProgram(...);
glDrawElements(...);
}
The performance increase from this may be significant in some apps and
negligible in others. It is especially noticable in the Torcs game (r300g):
Before: 15.4 fps
After: 20 fps
Also less looping over attribs in st_draw_vbo yields slight speed-up
in apps with lots of glDraw* calls.
|
|
This is redundant to pipe_draw_info::max_index and doesn't really fit
in the optimizations I plan.
|
|
|
|
We don't need to call bind_arrays in the vbo module if the states
which the function depends on are not dirty.
|
|
|
|
Remove redundant initialization from commit
3b01b52bd78e3d2fc857feacebd815a5fae00c94 noticed by tstellar.
|
|
Matches the drm and ddx.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
Some hardware needs to make a seperate copy of all levels to obey
max_lod, so simply do not define the last two levels instead of
clamping.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixes SCons build.
|
|
Because we only translate a subrange of the buffer.
|
|
I thought I couldn't skip emitting this packet in some cases.
Well it looks like I can.
|
|
|
|
|
|
|
|
but really wtf? all these PCI IDs need to be ripped out of here, its totally
unscalable and the drivers already have this info so could export it some better way.
tested by Darxus on #wayland.
|
