freedreno: fix compile error

Small typo introduced in a3ed98f.

Signed-off-by: Rob Clark <robclark@freedesktop.org>
i965: Fix glTexImage when packing alignment != cpp

Fixes texture corruption of Weston clients on cairo-glesv2 backend.
Commit 49ed599 introduced the bug.

Corruption occured when glTexSubImage called
intel_texsubimage_tiled_memcpy() with:
  x,y=10,9
  w,h=7,7
  format=GL_ALPHA(0x1906)
  type=GL_UNSIGNED_BYTE(0x1401)
  gl_format=MESA_FORMAT_A8(0x18)
  packing.alignemnt=4

The function miscalculated the source image's stride as w*cpp=7 without
taking into account the packing alignment. The actual stride was 8.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70435
Reported-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Tested-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by:Frank Henigman <fjhenigman@google.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
i965: Print more debuginfo in intel_texsubimage_memcpy()

Print info about packing, format, type, and tiling. This will help debug
future issues with this fastpath.

Reviewed-by: Frank Henigman <fjhenigman@google.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
svga: remove user-space vertex/index buffer code

The gallium vbuf module, which we've been using for some time now, takes
care of uploading user-space vertex/index data into real buffers.  The
upload code in the svga driver was unused.

Reviewed-by: José Fonseca <jfonseca@vmware.com>
glsl: silence unused 'var' variable warning

Reviewed-by: Paul Berry <stereotype441@gmail.com>
clover: Query maximum kernel block size from the device instead of the kernel object.

Based on a similar fix from Aaron Watry.  It seems unlikely that we
will ever need a kernel-specific setting for this, and the Gallium API
doesn't support it.  Remove kernel::max_block_size() altogether.
glx: Move the driver extension-loading to a helper function.

I'm planning on doing driver extension parsing from 3 places, and making
the extension loading step a bit longer.

Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
dri: Allow config options to be passed to the loader through extensions.

Turns out already we have this nice mechanism for providing optional
things from the driver to the loader, and I was going to have to rename
the public global symbol to avoid conflicts when doing megadrivers.

While the former __driConfigOptions is technically loader interface, this
is the only loader that made use of that symbol.  Continue paying
attention to it if we can't find the new option, to retain compatibility
with old drivers.

Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
dri: Move driver config options to dri driver extensions.

This way they aren't all sitting in the global namespace (with the same
name per driver).

Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
glx: Add an optional function call for getting the DRI driver interface.

The previous interface relied on a static struct, which meant that the
driver didn't get a chance to edit the struct before the struct got used.
For megadrivers, I want struct specific to the driver being loaded.

v2: Fix the prototype in the docs (caught by Marek).  Since the driver
    name was in the function, we didn't need to also pass it in.
v3: Fix asprintf error checking (caught by Matt's gcc).

Reviewed-by: Matt Turner <mattst88@gmail.com> (v1)
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
egl: Add an optional function call for getting the DRI driver interface.

v2: Fix asprintf error checking.

Reviewed-by: Matt Turner <mattst88@gmail.com> (v1)
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
gbm: Add support for the new __driDriverGetExtensions interface.

v2: Fix uninitialized variable use in the old-ABI case.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com> (v1)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
dri: Pass in the dlsym()ed driver extension to screen creation.

This will allow a megadrivers build to reference the actual driver being
loaded from the shared dri_util screen creation code.

v2: Fix indentation, fallback case in EGL (review by Emil).

Reviewed-by: Matt Turner <mattst88@gmail.com> (v1)
Reviewed-by: Chad Versace <chad.versace@linux.intel.com> (v1)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
dri: Implement a DRI vtable extension to replace the global driDriverAPI.

As we move to megadrivers, we are unable to build multiple drivers with
the same public global symbol per driver (Think an X Server with an intel
and a nouveau driver, and the X Server implementing indirect for both --
we have to actually talk to the right driver).  By slipping the
driDriverAPI vtable into the driver's extension list, we can replace the
usage of the global symbol with usage of the loader-dlsym()ed driver
information.

v2: Pull in the hunk to avoid crashing on null driver_extensions.  Thanks,
    Emil!

Reviewed-by: Matt Turner <mattst88@gmail.com> (v1)
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
i965: Build the driver into a shared mesa_dri_drivers.so .

Previously, we've split things such that mesa core is in libdricore,
exposing the whole Mesa core interface in the global namespace, and the
i965_dri.so code all links against that.  Along with polluting application
namespace terribly, it requires extra PLT indirections and prevents LTO.

Instead, we can build all of the driver contents into the same .so with
just a few symbols exposed to be referenced from the actual driver .so
file, allowing LTO and reducing our exposed symbol count massively.

FPS improvement on GLB2.7 with INTEL_NO_HW=1: 2.61061% +/- 1.16957% (n=50)
(without LTO, just the PLT reductions from this commit)

Note that the X Server requires commit
7ecfab47eb221dbb996ea6c033348b8eceaeb893 to successfully load this driver!

v2: Set a global driverAPI variable so loaders don't have to update to
    createNewScreen2() (though they may want to for thread safety).
v3: Drop AM_CPPFLAGS addition (Emil pointed out I'd missed some cflags
    that would be necessary, though only if we actually relied on them).
v4: Fix install with DESTDIR set.

Reviewed-by: Matt Turner <mattst88@gmail.com> (v1)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> (v2)
nouveau: Build the driver into the shared mesa_dri_drivers.so.

v2: drop dridir now that it's unused.
v3: Consistently put spaces around += in the updated Makefile.am block.
v4: Set a global driverAPI variable so loaders don't have to update to
    createNewScreen2() (though they may want to for thread safety).
v5: Fix missed public symbol in nouveau. (caught by Emil)

Reviewed-by: Matt Turner <mattst88@gmail.com> (v2)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
dri: Add a tool for generating #defines to namespace driver global symbols.

Acked-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
i915: Build the driver into the shared mesa_dri_drivers.so.

i915 has symbols for formerly-shared code that conflict with i965, so we
define them away using gen-symbol-redefs.py.  Options considered:

- This option.  Downsides: The symbols in profiling and debugging don't
  match the source.  The symbol list may change in the future and we won't
  notice without manually running the tool again.

- Use objcopy --localize-hidden to automatically demote our symbols to
  locals.  This didn't work on i965 due to c++ weak symbols (which can't
  be localized), but could work on i915.  We could do it on i915 only, but
  it does produce libtool warnings at link time due to libtool not knowing
  if the resulting .o file is safe to link (stupid libtool).  Plus you end
  up with different symbols of the same name, which is confusing for
  debugging too.  On the other hand, no future symbol conflicts long term.

- Write our own libelf tool that handles c++ weak symbols like we want and
  apply it to all drivers.  All the downsides of above, but applies
  uniformly across drivers.

- Edit the files to just rename all the i915 or i965 symbols that
  conflict.  There are on the order of 100 that have a prefix we used to
  share, so it would take a bit of typing.  Fewest downsides, but still
  can have conflicts long term.

Ultimately, this is the least invasive change at the moment, and we can
see if the "more symbol conflicts appear later" thing is a real concern or
not.

Note that the ability to compile a version of i915 without INTEL_DEBUG env
support is dropped.  It's too useful.

v2: drop dridir now that it's unused.
v3: Consistently put spaces around += in the updated Makefile.am block.
v4: Set a global driverAPI variable so loaders don't have to update to
    createNewScreen2() (though they may want to for thread safety).

Reviewed-by: Matt Turner <mattst88@gmail.com> (v2)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
radeon: Build the driver into the shared mesa_dri_drivers.so.

This required some reordering of headers to ensure that the symbol name
redefines happened before any prototypes.

v2: drop dridir now that it's unused.
v3: Consistently put spaces around += in the updated Makefile.am blocks.
v4: Set a global driverAPI variable so loaders don't have to update to
    createNewScreen2() (though they may want to for thread safety).

Reviewed-by: Matt Turner <mattst88@gmail.com> (v2)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
swrast: Build the driver into the shared mesa_dri_drivers.so.

v2: drop dridir now that it's unused.
v3: Fix linking after rebase when building just swrast from classic but a
    drm-using gallium driver.
v4: Consistently put spaces around += in the updated Makefile.am block.
v5: Set a global driverAPI variable so loaders don't have to update to
    createNewScreen2() (though they may want to for thread safety).

Reviewed-by: Matt Turner <mattst88@gmail.com> (v3)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>