This reverts commit 363b53f00069af718f64cf047f19ad5681a8bf6d.

This reverts commit c46c551c56f78c6bf9e63524c89478695fc4f525.

Prefer blit-based texture transfers only if the chip declares to have
dedicated VRAM. For shared-memory systems if will be more efficient to
disable this capability.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reported-by: Ilia Mirkin <imirkin@alum.mit.edu>

GK20A does not have dedicated VRAM, therefore allocating in VRAM can be
sub-optimal and sometimes even harmful. Set its VRAM domain to
NOUVEAU_BO_GART so all objects are allocated in system memory.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>

Use the newly-introduced NV_VRAM_DOMAIN() macro to support alternative
VRAM domains for chips that do not use dedicated video memory.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>

Some NVIDIA chips (e.g. GK20A) do not embed VRAM of their own and have
complete shared access to system memory. For these systems, allocating
objects in VRAM might lead to unneeded copies and sub-optimal memory
management. It will also lead to errors if the kernel does not allow
VRAM objects allocations.

This patch adds a vram_domain member to struct nouveau_screen that can
optionally be initialized to an alternative domain to use for VRAM
allocations (most likely, NOUVEAU_BO_GART to allocate everything in
system memory). If not initialized, the default NOUVEAU_BO_VRAM domain
is used.

Code that allocates GPU objects is then expected to use the
NV_VRAM_DOMAIN() macro in place of NOUVEAU_BO_VRAM to ensure correct
behavior on VRAM-less chips.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

This should be more efficient than the previous snprintf() solution.
But more importantly, it avoids a buffer overflow bug that could result
in crashes or unpredictable results when processing very large interface
blocks.

For the app in question, key->length = 103 for some interfaces.  The check
if size >= sizeof(hash_key) was insufficient to prevent overflows of the
hash_key[128] array because it didn't account for the terminating zero.
In this case, this caused the call to hash_table_string_hash() to return
different results for identical inputs, and then shader linking failed.

This new solution also takes all structure fields into account instead
of just the first 15 when sizeof(pointer)==8.

Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 31667e6237d30188d0b29e17f5b9892f10c0d83a)