| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
The cache lookup of these two little floats was .12% of total CPU time
on firefox-talos-gfx because we did it any time commonly-changed state
changed. On the other hand, updating the CC VP bo immediately whenver
CC VP state changes is a .07% overhead due to putting a driver hoook
in glEnable().
|
|
|
|
It's more likely that we wrap badly in state setup than in the little
primitive packet.
|
|
It just duplicated the default/core Mesa behaviour.
|
|
Update for recent removal of demos and additions of new displays and
functions.
|
|
The KMS backend requires a hardware pipe driver. Do not build
egl_kms_swrast. Also, only build egl_fbdev_swrast for fbdev backend.
It is a pure software backend.
|
|
The backend is pure software. It implements EGL_MESA_screen_surface
extension, and is kept simple by only exporting the current mode.
|
|
This is a simple winsys that mmap()s the framebuffer device and
memcpy()s the contents of display targets to the framebuffer device for
displaying.
|
|
|
|
|
|
|
|
done to handle strips correctly as inputs - we need to decompose
the strips
|
|
|
|
don't overwrite the inputs and make sure the correct primitive
is used on entry
|
|
|
|
|
|
|
|
Drivers still reject them today, but cairo would like to use these.
|
|
It looks like we were reading a fractional value, multiplying by an
enormous negative value, then stuffing that value into a bitfield
assuming it was already clamped. This becomes relevant for GL_ALPHA
or R/RG FBOs.
|
|
This avoids many pipeline stalls in cairo-gl.
[ # ] backend test min(s) median(s) stddev. count
Before:
[ 0] gl firefox-talos-gfx 36.799 36.851 2.34% 3/3
[ 0] gl firefox-talos-svg 33.429 35.360 3.46% 3/3
After:
[ 0] gl firefox-talos-gfx 35.895 36.250 0.48% 3/3
[ 0] gl firefox-talos-svg 26.669 29.888 5.34% 3/3
This doesn't avoid all the pipeline stalls because the kernel reports
!busy for buffers on the flushing list. That should be fixed in .36.
|
|
In exchange we end up with an extra memcpy, but that seems better than
calloc/free. Each buffer is 4k maximum, and on the i965-streaming
branch this allocation was showing up as the top entry in
brw_validate_state profiling for cairo-gl.
|
|
I was told this wouldn't help to fix the FDO bug #28443, but still,
it's a harmless last resort.
Also, linear textures safely fallback to an unpipelined transfer here.
|
|
|
|
|
|
|
|
|
|
fixes bug 28450.
|
|
|
|
|
|
|
|
of vertices
lots and lots of fixes for geometry shaders. in particular now we work when the gs
emits a different primitive than the one the pipeline was started with and also
we work when gs emits more vertices than would fit in the original buffer.
|
|
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
If no customizer is present, 3D will be enabled by default.
Otherwise the option will default to the customizer value.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
