loader: ifdef libdrm specific code and include

Mesa provides the flexibility of building without the
need to have libdrm present on the system. The situation
has regressed with the recent commit

commit 8c2e7fd8460750543367053b1be9368cc38e1d6a
Author: Emil Velikov <emil.l.velikov@gmail.com>
Date:   Fri Jan 10 23:36:16 2014 +0000

    loader: introduce the loader util lib

By isolating libdrm code by #ifndef __NOT_HAVE_DRM_H we
can have libdrm-less builds on across all build systems.

This patch converts Android's _EGL_NO_DRM to __NOT_HAVE_DRM_H
to provide consistency with the other cases within mesa, allows
compilation of libloader on libdrm-less scons and conditionally
links against libdrm if present under automake.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73776
BUgzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73777
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
pipe-loader: Fix build

pipe_loader_drm.c: In function 'pipe_loader_drm_probe_fd':
pipe_loader_drm.c:120:4: error: implicit declaration of function 'loader_get_pci_id_for_fd' [-Werror=implicit-function-declaration]

Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
st/vdpau: don't return a device if the screen doesn't support NPOT

NV3x cards don't support NPOT textures. Technically this restriction
could be worked around, but since it also doesn't expose any video
decoding hw, just turn it off entirely.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: 10.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Christian König <christian.koenig@amd.com>
st/vdpau: fix bogus error handling in output/bitmap creation

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Christian König <christian.koenig@amd.com>
st/vdpau: check surface params before creating surfaces

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Christian König <christian.koenig@amd.com>
i965: Only update renderbuffers on initial intelMakeCurrent

We call intel_prepare_render() in intelMakeCurrent() to make sure we have
renderbuffers before calling _mesa_make_current().  The only reason we
do this is so that we can have valid defaults for width and height.
If we already have buffers for the drawable we're making current, we
don't need this step.

In itself, this is a small optimization, but it also avoids a round trip
that could block on the display server in a unexpected place.

https://bugs.freedesktop.org/show_bug.cgi?id=72540
https://bugs.freedesktop.org/show_bug.cgi?id=72612

Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965/blorp: remove dependency to compression control state

Effectively only the mask control bit gets altered for the single
addition in question and hence there is no real need to use a
fresh state control level for it -- that is more useful when
multiple intructions share the same mask and compression settings.

This is a preparation step for removing the explicit compression
control modifiers in the blit compiler. After this patch there
are no nested state control levels making the constant nature of
the compression settings more apparent.

No regressions on IVB (piglit quick + unit tests).

v2 (Matt, Ian): use temporary variable instead of assigning
                directly on the same line with a function call.

Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/blorp: reduce the scope of the explicit compression control

By highlighting these special cases makes it clearer to switch
to the fs-generator as the wider scoped compression control
settings used in the current implementation can be simply
dropped.

No regressions on IVB (piglit quick + unit tests).

v2 (Ian): typo in a comment

Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
logger: s/\<log\>/log_/

Currently the MSVC build is broken because of conflicting definitions of
'log' function.  I didn't investigate thoroughly, but I suspect the
it is conflicting standard math.h's log.

log_ is admittedly not a great name, but it is better than a broken build.
A better one can be used in a follow-on build.
logger: Remove unused variable.

Silences gcc "unused variable ‘buf’" warning.

Trivial.
i915,r200,radeon,vega: Change vendor from "VMware, Inc." to "Mesa Project".

These are components which were originally developed by Tungsten Graphics,
which was in turn acquired by VMware, but are de facto now being maintained
by third-party contributors of the Mesa open-source community.

This matches what's reported by swrast driver and a few other components.

Suggested by Ian Romanick.
st/vdpau: s/surface/resource/ to fix compiler warning

Reviewed-by: Christian König <christian.koenig@amd.com>
softpipe: fix crash when accessing null colorbuffer

Fixes piglit fbo-missing-attachment-blit test.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73755

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
swrast: check for null/-1 when mapping renderbuffers

Fixes fbo-drawbuffers-none crash (but test still fails).
https://bugs.freedesktop.org/show_bug.cgi?id=73757

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
draw: clean up d3d style point clipping

Instead of skipping x/y clipping completely if there's point_tri_clip points
use guard band clipping. This should be easier (previously we could not disable
generating the x/y bits in the clip mask for llvm path, hence requiring custom
clip path), and it also allows us to enable this for tris-as-points more easily
too (this would require custom tri clip filtering too otherwise). Moreover,
some unexpected things could have happen if there's a NaN or just a huge number
in some tri-turned-point, as the driver's rasterizer would need to deal with it
and that might well lead to undefined behavior in typical rasterizers (which
need to convert these numbers to fixed point). Using a guardband should hence
be more robust, while "usually" guaranteeing the same results. (Only "usually"
because unlike hw guardbands draw guardband is always just twice the vp size,
hence small vp but large points could still lead to different results.)
Unfortunately because the clipmask generated is completely unaffected by guard
band clipping, we still need a custom clip stage for points (but not for tris,
as the actual clipping there takes guard band into account).

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
docs: note reduced display list memory usage in 10.1 relnotes
draw: fix incorrect vertex size computation in LLVM drawing code

We were calling draw_total_vs_outputs() too early.  The call to
draw_pt_emit_prepare() could result in the vertex size changing.
So call draw_total_vs_outputs() after draw_pt_emit_prepare().

This fix would seem to be needed for the non-LLVM code as well,
but it's not obvious.  Instead, I added an assertion there to
try to catch this problem if it were to occur there.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72926
Cc: 10.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
draw: whitespace and formatting fixes in draw_pt_fetch_shade_pipeline*.c

Trivial.
draw: use some cast wrappers in draw_pt_fetch_shade_pipeline*.c

Trivial.