| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Fixes glsl-vs-vec4-indexing-4.
|
|
|
|
Missed this while hacking in constants support. Fixes:
glsl-algebraic-mul-*
glsl-algebraic-rcp-*
glsl-vs-swizzle-swizzle-lhs
glsl-vs-vec4-indexing-6
|
|
This should be resolved with linker.cpp's location assignment, as
currently we drop that location assignment on the ground. However,
this gets basic programs using uniforms working for now.
|
|
This cuts runtime by around 20% from talloc_parent() lookups.
|
|
The 965 driver can now run a glsl2-generated shader!
|
|
|
|
|
|
The compiler is now called by the driver, and generates program
instructions. Parameter lists are still not set up, so the driver
chokes on it shortly thereafter.
|
|
|
|
|
|
The assembly parser is already checking this, but we're relying on the
symbol table handling it in glsl2.
|
|
width/height may not be a multiple of blocksize (small mip levels / npot
textures). This should be handled just fine.
Fixes #28530.
|
|
See bug 28577 for details.
NOTE: this is a candidate for the 7.8 branch.
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
This reverts commit a9ee95651131e27d5acf3d10909b5b7e5c8d3e92.
It was based on a failure to understand how ther driver allocates
memory, and causes a regression with Celestia.
Set MaxLevel to dstLevel before allocating new mipmap level.
The radeon driver will fail to allocate space for a new level that
is outside of BaseLevel..MaxLevel. Set MaxLevel before allocating.
Signed-off-by: Maciej Cencora <m.cencora@gmail.com>
|
|
Fixes segfault in mipmap_view.c demo. Bug #27212.
|
|
|
|
|
|
|
|
|
|
When building OSMesa and xlib GL, the resulting OSMesa would be linked
against libGL instead of the internal mesa libraries. However, when
building with -fvisibility=hidden, some of the internal functions used
in OSMesa could not be resolved through libGL.
Instead, always build OSMesa standalone without linking against libGL.
This has the advantage that OSMesa is always built the same way, but it
means that disk space is wasted when libGL is installed since both
libraries will contain the internal objects.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
Tested-by: Tom Fogal <tfogal@alumni.unh.edu>
|
|
If the default framebuffer is bound to <target>, then
<attachment> must be one of FRONT_LEFT, FRONT_RIGHT, BACK_LEFT,
BACK_RIGHT, AUXi, DEPTH_BUFFER, or STENCIL_BUFFER, identifying a
color buffer, the depth buffer, or the stencil buffer, and
<pname> may be FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE or
FRAMEBUFFER_ATTACHMENT_OBJECT_NAME.
as well as these <pname> values
FRAMEBUFFER_ATTACHMENT_RED_SIZE,
FRAMEBUFFER_ATTACHMENT_GREEN_SIZE,
FRAMEBUFFER_ATTACHMENT_BLUE_SIZE,
FRAMEBUFFER_ATTACHMENT_ALPHA_SIZE,
FRAMEBUFFER_ATTACHMENT_DEPTH_SIZE,
FRAMEBUFFER_ATTACHMENT_STENCIL_SIZE,
FRAMEBUFFER_ATTACHMENT_COMPONENT_TYPE, or
FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING.
https://bugs.freedesktop.org/show_bug.cgi?id=28551
|
|
|
|
I broke this with the state streaming changes.
|
|
|
|
BOs are stored in the bufmgr, which is freed as part of the screen
structure.
|
|
|
|
|
|
|
|
|
|
|
|
before:
[ # ] backend test min(s) median(s) stddev. count
[ 0] gl firefox-talos-gfx 31.791 32.287 1.11% 6/6
after:
[ 0] gl firefox-talos-gfx 31.198 31.675 0.96% 6/6
|
|
|
|
|
|
|
|
|
|
|
|
|
|
e.g. for(i=10; i>0; i--)
|
|
This only works with for loops that increment the counter.
e.g. for(i=0; i<10; i++)
|
|
The loop emulation unrolls loops as may times as possbile while still
keeping the shader program below the maximum instruction limit. At this
point, there are no checks for constant conditionals. This is only enabled
for fragment shaders.
|
|
We had to fill out all that junk when using the cache, but no more.
|
|
|
|
This makes the binding table code simpler, and is required for gen6,
which requires binding table addresses to be under 64k offset from the
surface state base addr.
No significant change in performance on firefox-talos-gfx.
|
|
Now that the binding table is streamed indirect state, they were
always NULL/0.
|
|
|
|
It turns out that computing a 56 byte key to look up a 20-byte object
out of a hash table was some sort of a bad idea. Whoops.
before:
[ # ] backend test min(s) median(s) stddev. count
[ 0] gl firefox-talos-gfx 37.799 38.203 0.39% 6/6
after:
[ 0] gl firefox-talos-gfx 34.761 34.784 0.17% 5/6
|
|
This slightly reduces reduces cairo-gl firefox-talos-gfx runtime on my
Ironlake:
before:
[ # ] backend test min(s) median(s) stddev. count
[ 0] gl firefox-talos-gfx 38.236 38.383 0.43% 5/6
after:
[ 0] gl firefox-talos-gfx 37.799 38.203 0.39% 6/6
It turns out the cost of caching these objects and looking them up in
the cache again is greater than the cost of just computing the object
again, particularly when the overhead of having a separate BO to pin
is removed.
(Those that are paying close attention will note that this is a
reversal of the path I was moving the driver in a couple of years ago.
The major thing that has changed is that back then all state was
recomputed when we wrapped the streaming state buffer, including
recompiling our precious programs. Now, we're uncaching just the
objects that are cheap to compute, and retaining caching of expensive
objects)
|
|
This was bothering me when redoing the binding tables.
|
