i965/vec4: Drop writemasks on scratch reads.

This code is complete nonsense and has apparently existed since I first
implemented register spilling in the VS two years ago.

Scratch reads are SEND messages, which ignore the destination writemask.

The comment about "data that may not have been written to scratch" is
also confusing - we always spill whole 4x2 registers, so such data
simply does not exist.  We can safely ignore the writemask.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
freedreno: helper to calc layer/level offset

Rather than duplicating this everywhere.  Especially as on a4xx the
layout of layers and levels differs based on texture type.

Signed-off-by: Rob Clark <robclark@freedesktop.org>
freedreno: add is_a3xx()/is_a4xx() helpers

A bunch of open-coded 'gpu_id > 300's seems like it will eventually
cause problems with future generations.  There were already a few minor
problems with caps for features that still need additional work on a4xx.

Signed-off-by: Rob Clark <robclark@freedesktop.org>
freedreno: update generated headers

Signed-off-by: Rob Clark <robclark@freedesktop.org>
freedreno/a4xx: mipmaps

Signed-off-by: Rob Clark <robclark@freedesktop.org>
docs: Update 10.4.0 release notes

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit 5fe79b0b1272d530371a5d7248ed378cff4f6d21)
docs: Add 10.4 sha256 sums, news item and link release notes

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit af0c82099b955f10471c15cb7a4dc8db29b84963)

Conflicts:
	docs/index.html
	docs/relnotes.html
glx/dri3: Fix glXWaitForSbcOML() to handle targetSBC==0 correctly. (v2)

targetSBC == 0 is a special case, which asks the function
to block until all pending OpenGL bufferswap requests have
completed.

Currently the function just falls through for targetSBC == 0,
returning bogus results.

This breaks applications originally written and tested against
DRI2 which also rely on this not regressing under DRI3/Present,
e.g., Neuro-Science software like Psychtoolbox-3.

This patch fixes the problem.

v2: Simplify as suggested by Axel Davy. Add comments proposed
by Eric Anholt.

Cc: "10.3 10.4" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Eric Anholt <eric@anholt.net>
glx/dri3: Track separate (ust, msc) for PresentPixmap vs. PresentNotifyMsc (v2)

Prevent calls to glXGetSyncValuesOML() and glXWaitForMscOML()
from overwriting the (ust,msc) values of the last successfull
swapbuffers call (PresentPixmapCompleteNotify event), as
glXWaitForSbcOML() relies on those values corresponding to
the most recent completed swap, not to whatever was last
returned from the server.

Problematic call sequence without this patch would have been, e.g.,

glXSwapBuffers()
... wait ...
swap completes -> PresentPixmapComplete event -> (ust,msc)
updated to reflect swap completion time and count.
... wait for at least 1 video refresh cycle/vblank increment.

glXGetSyncValuesOML()
-> PresentNotifyMsc event overwrites (ust,msc) of swap
completion with (ust,msc) of most recent vblank

glXWaitForSbcOML()
-> Returns sbc of last completed swap but (ust,msc) of last
completed vblank, not of last completed swap.
-> Client is confused.

Do this by tracking a separate set of (ust, msc) for the
dri3_wait_for_msc() call than for the dri3_wait_for_sbc()
call.

This makes the glXWaitForSbcOML() call robust again and restores
consistent behaviour with the DRI2 implementation.

Fixes applications originally written and tested against
DRI2 which also rely on this not regressing under DRI3/Present,
e.g., Neuro-Science software like Psychtoolbox-3.

This patch fixes the problem.

v2: Rename vblank_msc/ust to notify_msc/ust as suggested by
Axel Davy for better clarity.

Cc: "10.3 10.4" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
glx/dri3: Request non-vsynced Present for swapinterval zero. (v3)

Restores proper immediate tearing swap behaviour for
OpenGL bufferswap under DRI3/Present.

Cc: "10.3 10.4" <mesa-stable@lists.freedesktop.org>

v2: Add Frank Binns signed off by for his original earlier
patch from April 2014, which is identical to this one, and
Chris Wilsons reviewed tag from May 2014 for that patch, ergo
also for this one.

v3: Incorporate comment about triple buffering as suggested
by Axel Davy, and reference to relevant spec provided by
Eric Anholt.

Signed-off-by: Frank Binns <frank.binns@imgtec.com>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Eric Anholt <eric@anholt.net>
glx/dri3: Don't fail on glXSwapBuffersMscOML(dpy, window, 0, 0, 0) (v2)

glXSwapBuffersMscOML() with target_msc=divisor=remainder=0 gets
translated into target_msc=divisor=0 but remainder=1 by the mesa
api. This is done for server DRI2 where there needs to be a way
to tell the server-side DRI2ScheduleSwap implementation if a call
to glXSwapBuffers() or glXSwapBuffersMscOML(dpy,window,0,0,0) was
done. remainder = 1 was (ab)used as a flag to tell the server to
select proper semantic. The DRI3/Present backend ignored this
signalling, treated any target_msc=0 as glXSwapBuffers() request,
and called xcb_present_pixmap with invalid divisor=0, remainder=1
combo. The present extension responded kindly to this with a
BadValue error and dropped the request, but mesa's DRI3/Present
backend doesn't check for error codes. From there on stuff went
downhill quickly for the calling OpenGL client...

This patch fixes the problem.

v2: Change comments to be more clear, with reference to
relevant spec, as suggested by Eric Anholt.

Cc: "10.3 10.4" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Eric Anholt <eric@anholt.net>
util/hash_table: Rework the API to know about hashing

Previously, the hash_table API required the user to do all of the hashing
of keys as it passed them in.  Since the hashing function is intrinsically
tied to the comparison function, it makes sense for the hash table to know
about it.  Also, it makes for a somewhat clumsy API as the user is
constantly calling hashing functions many of which have long names.  This
is especially bad when the standard call looks something like

_mesa_hash_table_insert(ht, _mesa_pointer_hash(key), key, data);

In the above case, there is no reason why the hash table shouldn't do the
hashing for you.  We leave the option for you to do your own hashing if
it's more efficient, but it's no longer needed.  Also, if you do do your
own hashing, the hash table will assert that your hash matches what it
expects out of the hashing function.  This should make it harder to mess up
your hashing.

v2: change to call the old entrypoint "pre_hashed" rather than
    "with_hash", like cworth's equivalent change upstream (change by
    anholt, acked-in-general by Jason).

Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
hash_table: Fix compiler warnings from the renaming.

Not sure how we both missed this.  None of the callers were using the
return value, though.
vc4: Fix a leak of the simulator's exec BO's actual vc4_bo.
vc4: Fix leak of simulator memory on screen cleanup.
vc4: Switch to using the util/ hash table.

No performance difference on a microbenchmark with norast that should hit it
enough to have mattered, n=220.
vc4: Fix leak of a copy of the scheduled QPU instructions.

They're copied into a vc4_bo after compiling is done.
vc4: Fix leak of the compiled shader programs in the cache.
vc4: Fix leak of vc4_bos stashed in the context.
vc4: Fix leaks of the CL contents.