This really makes more sense in the intel_batchbuffer struct.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

fast_clear_op is leftover from the meta-fast-clear days.
No idea what the other thing was for, but it isn't used now.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

Currently all the build systems but Meson generate the header in
src/mapi/glapi. Meson cannot do that since:
 - it does not allow user control over the location of output files
 - moving the generation rule(s) causes explosion due to the unusual
structure of glapi and friends
 - copying the file into the correct location is a non-trivial task

To workaround the above deficiency in the least invasive way, let's
adjust the #include directive and add a few -I flags to the autotools
build.

Note: both builddir and srcdir, should be used. Otherwise building from
a release tarball fails badly.

Cc: Dylan Baker <dylanx.c.baker@intel.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Tested-by: Mark Janes <mark.a.janes@intel.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>

Since blob.h moved up to src/compiler the test should include that
instead of src/compiler/glsl

fixes: 0e3bd56c6e ("compiler: Move blob up a level")
Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>

This reverts commit fc48ad2427.

There commit reference the previous commit as it justification of
changing behaviour. Although unlike the said commit, there's nothing
obviously wrong there.

I'll take a look close why Meson fails to pick the file, but in the
interim reverting this commit fixes the normal distcheck target.

Necessary to support P010/P016 surfaces for video.

Signed-off-by: Mark Thompson <sw@jkqxz.net>
Acked-by: Leo Liu <leo.liu@amd.com>

Commit 731ba6924a
"expose RGBA visuals only on Android" replaced
ARRAY_SIZE(formats) by num_formats, but there are
3 loops which add configs, and only one was updated
to num_formats.

Also update loops for configs with accumulation buffer
and multisample configs.

Fixes: 731ba6924a "i965: expose RGBA visuals only on Android"
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>

Coverage and LTO seems to be hard requirements for Clang, while
coroutines is needed as of LLVM/Clang 4.0.

Mark the last one as "optional" so we handle every case.

Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Tobias Droste <tdroste@gmx.de>

We want to add "optional" components, which have been added with later
LLVM versions.

One such in-tree example is inteljitevents. Others are to follow
shortly.

v2: Use the correct function, add blank line between functions (Tobias)

Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Tobias Droste <tdroste@gmx.de>

Otherwise we error out at link stage as follows:

/usr/lib/llvm-3.9/lib/libLLVMAMDGPUCodeGen.a(R600OptimizeVectorRegisters.cpp.o):
unrecognized relocation (0x2a) in section
`.text._ZNK12_GLOBAL__N_119R600VectorRegMerger16getAnalysisUsageERN4llvm13AnalysisUsageE'
/usr/bin/ld: final link failed: Bad value

Cc: mesa-stable@lists.freedesktop.org
Cc: Jan Vesely <jan.vesely@rutgers.edu
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>

Earlier versions need different quirks, but as of LLVM 3.9 llvm-config
provides --link-shared/link-static toggles.

The output of which seems to be reliable - looking at LLVM 3.9, 4.0 and
5.0.

Note that there are earlier code will be used for pre LLVM 3.9 and is
unchanged.

This effectively fixes LLVM static linking, while providing a clearer
and more robust solution for future versions.

Mildly interesting side notes:

 - build-mode (introduced with 3.8) was buggy with 3.8
It shows "static" when build with -DLLVM_LINK_LLVM_DYLIB=ON, yet it was
consistent with --libs. The latter shows the static libraries.

 - libnames and libfiles are broken with LVM 3.9
The library prefix and extension is printed twice liblibLLVM-3.9.so.so

v2: Invoke llvm-config twice, instead of using sed, to combine the two
lines into one (Tobias)

Cc: mesa-stable@lists.freedesktop.org
Cc: Dieter Nützel <Dieter@nuetzel-hh.de>
Cc: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Tobias Droste <tdroste@gmx.de>

As of LLVM 3.9 one could use consistent ways to handle the component.
Factor out the current handling, as it will be used for older versions.

Cc: mesa-stable@lists.freedesktop.org
Cc: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Tobias Droste <tdroste@gmx.de>

Prior to the refactor/cleanup by Tobias one could add an invalid
component to LLVM_COMPONENTS.

Since that's no longer the case we can drop the current check.

Cc: Tobias Droste <tdroste@gmx.de>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Tobias Droste <tdroste@gmx.de>

The user does not need to know the specifics of the struct, as only a
pointer to it is used.

Just forward declare the struct making the header self-contained.

v2: Remove deprecation warning text/bugzilla - patch does no help there.

Cc: Greg V <greg@unrelenting.technology>
Fixes: 5cddb1ce3c ("wayland: Add an extension to create wl_buffers from
EGLImages")
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (v1)

The only driver that utilises Clover already depends on LLVM 3.9.
Close to every supported distribution has said version.

Additionally libclc also requires LLVM 3.9.

With this in mind, we can safely bump the requirement.

There is a handful of dead code that we could remove, which will be
resolved with later commits.

Note: this drops the LLVM 3.6 build from the Travis build. LLVM 3.9 (and
later) are already covered in there.

https://lists.freedesktop.org/archives/mesa-dev/2017-September/170028.html

v2: Add reference to discussion thread (Eric), adjust libclc LLVM req.
(Jan).

Cc: Aaron Watry <awatry@gmail.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Acked-by: Vedran Miletić <vedran@miletic.net>
Acked-by: Jan Vesely <jan.vesely@rutgers.edu>
Acked-by: Francisco Jerez <currojerez@riseup.net>

Now that wayland-drm (correctly) keeps a local copy of the callbacks,
this should not longer cause explosions.

After all the symbol is a local, constant data.

Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Tested-by: Derek Foreman <derekf@osg.samsung.com>

The callbacks may be called even when they are no longer valid.
Say, the user is dlclose(ing) libEGL while the buffers are being
destroyed.

Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Tested-by: Derek Foreman <derekf@osg.samsung.com>

The __DRI_IMAGE version can be 17 or over, while the function pointer is
NULL. Guard for that instead of crashing.

Fixes: bad24395d9 ("egl/dri: use createImageFromRenderbuffer2 when
available")
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

Build i915 with meson. More or less copied from i965, with all
the unneeded cruft removed, and the libdrm_intel dependency added.

Cc: Dylan Baker <dylan@pnwbakers.com>
Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>

The pkg-config file is called xxf86vm.pc not xf86vm.pc.

Cc: Dylan Baker <dylan@pnwbakers.com>
Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>

This is a lot more natural than special casing it all over the place.
We still have to do a bit of special-casing in assign_constant_locations
but it's not special-cased quite as bad as it was before.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Now that everything is nicely ralloc'd, we can allocate the pull_param
array in assign_constant_locations instead of higher up.  We can also
re-allocate the param array so that it's exactly the needed size.  This
should save us some memory because we're not allocating the total needed
param space for both push and pull.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Now that we're always growing the param array as-needed, we can
allocate the param array in common code and stop repeating the
allocation everywere.  In order to keep things sane, we ralloc the
[pull_]param array off of the compile context and then steal it back
to a NULL context later.  This doesn't get us all the way to where
prog_data::[pull_]param is purely an out parameter of the back-end
compiler but it gets us a lot closer.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Ian Romanick <idr@freedesktop.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Now that the only thing we put in the array up-front are client push
constants, we can simplify anv_pipeline_compile a bit.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Before, we were calculating up-front and then filling in later.  Now we
just grow as needed in anv_nir_apply_pipeline_layout.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

This way any image uniforms end up having locations higher than
MAX_PUSH_CONSTANT_SIZE.  There's no bug here at the moment, but this
consistency will make the next commit easier.  Also, because
nir_apply_pipeline_layout properly increments nir->num_uniforms when
it expands the param array, we no longer need to stomp it to match
prog_data::nr_params because it already does.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Instead of requiring the caller of brw_compile_vs to figure it out, just
grow the param array on-demand.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Instead of making the caller of brw_compile_cs add something to the
param array for thread_local_id_index, just add it on-demand in
brw_nir_intrinsics and grow the array.  This is now safe to do because
everyone is now using ralloc for prog_data::param.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

It's already only ever called from brw_compile_cs and only handles
compute intrinsics.  Let's just make it CS-specific.  We can always
make it handle other stages again later if we want.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

We haven't needed this ever since we started using NIR for lowering
rectangle textures.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Otherwise, in the ARB program case _mesa_add_state_reference may grow
the parameter array which will cause brw_nir_setup_arb_uniforms to write
past the end of the param array because it only looks at the parameter
list length but the parma array is allocated based on nir->num_uniforms.
The only reason this hasn't caused us problems is because we are padding
out the param array for fragment programs unnecessarily.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

The Vulkan driver does not support pull constants.  It simply limits
things such that we can always push everything.  Previously, we were
determining whether or not to push things based on whether or not the
prog_data::pull_param array is non-null.  This is rather hackish and
about to stop working.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

This way we stop leaking it.  This is completely safe because, when we
hand it off to anv_shader_bin_create or anv_pipeline_cache_upload_kernel,
they make a copy of the entire param array.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

This lets us avoid some of the manual ralloc stealing and prepares for
future commits in which we will want to ralloc prog_data::param.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

This burns an extra 10k of memory or so in the case where you don't have
any images.  However, if you have several shaders which use images, this
should be much less memory.  It also gets rid of a part of prog_data
that really has nothing to do with the compiler.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

This should be just as good as looking in prog_data but removes our one
state setup dependency on brw_stage_prog_data::nr_image_param.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

This moves us away to the array of pointers model and onto a model where
each param is represented by a generic uint32_t handle.  We reserve 2^16
of these handles for builtins that get generated by somewhere inside the
compiler and have well-defined meanings.  Generic params have handles
whose meanings are defined by the driver.

The primary downside to this new approach is that it moves a little bit
of the work that we would normally do at compile time to draw time.  On
my laptop this hurts OglBatch6 by no more than 1% and doesn't seem to
have any measurable affect on OglBatch7.  So, while this may come back
to bite us, it doesn't look too bad.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

The only thing it was handling was push constants.  We pull the actual
constant upload code into gen6_constant_state.c and the atoms into
genX_state_upload.c.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

This looks like a copy+paste error.  They don't actually write into that
variable as would be implied by putting the return there.

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable@lists.freedesktop.org

We didn't fold correctly in the case of 0x1 because we never let the
loop counter hit 0.  Switching it to bit >= 0 solves this problem.

Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Cc: mesa-stable@lists.freedesktop.org

Acked-by: Kenneth Graunke <kenneth@whitecape.org>

This gets rid of all of our hand-rolled size calculation and
serialization code and replaces it with safe "standards" that are used
elsewhere in anv and mesa.  This should be significantly safer than
rolling our own.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

This is just a trivial cleanup.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

There are certain advantages to using uint8_t internally such as
well-defined arithmetic on all platforms.  However, interfaces that
work in terms of raw data should use a void* type.

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>