GitLab

Almost every driver already supported it.  All current and future
Gallium drivers always support it, and most existing classic drivers
support it.

This only changes radeon and nouveau.

This extension only adds data types that can be passed to, for example,
glTexImage2D.  It does not add internal formats.  Since you can already
pass GL_FLOAT to glTexImage2D this shouldn't pose any additional issues
with those drivers.  Note that r200 and i915 already supported this
extension, and they don't support floating-point textures either.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

this just ties the mesa code to the pre-existing gallium interface,
I'm not sure what to do with the CSO stuff yet.

0.2: fix min/max bounds
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Dave Airlie <airlied@redhat.com>

v2: adjust limits for radeonsi and llvmpipe
v3: add documentation

Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>

This can be derived from the shader caps.

All GPUs from ATI/AMD, NVIDIA, and INTEL have separate texture slots
for each shader stage.

Every driver supports it.  All current and future Gallium drivers always
support it, and all existing classic drivers support it.

v2: Making GL_ARB_map_buffer_alignment a desktop OpenGL extension only.

v3: Squash two commits together.

v4 (idr): MIN_MAP_BUFFER_ALIGNMENT queries don't have any dependencies.
In previous versions of the patch it depended on EXTRA_API_GL which
would prevent the query from working in core profile contexts.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

Every driver supports it.  All current and future Gallium drivers always
support it, and all existing classic drivers support it.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Reviewed-by: Marek Olšák <marek.olsak@amd.com>

Tungsten Graphics Inc. was acquired by VMware Inc. in 2008.  Leaving the
old copyright name is creating unnecessary confusion, hence this change.

This was the sed script I used:

    $ cat tg2vmw.sed
    # Run as:
    #
    #   git reset --hard HEAD && find include scons src -type f -not -name 'sed*' -print0 | xargs -0 sed -i -f tg2vmw.sed
    #

    # Rename copyrights
    s/Tungsten Gra\(ph\|hp\)ics,\? [iI]nc\.\?\(, Cedar Park\)\?\(, Austin\)\?\(, \(Texas\|TX\)\)\?\.\?/VMware, Inc./g
    /Copyright/s/Tungsten Graphics\(,\? [iI]nc\.\)\?\(, Cedar Park\)\?\(, Austin\)\?\(, \(Texas\|TX\)\)\?\.\?/VMware, Inc./
    s/TUNGSTEN GRAPHICS/VMWARE/g

    # Rename emails
    s/alanh@tungstengraphics.com/alanh@vmware.com/
    s/jens@tungstengraphics.com/jowen@vmware.com/g
    s/jrfonseca-at-tungstengraphics-dot-com/jfonseca-at-vmware-dot-com/
    s/jrfonseca\?@tungstengraphics.com/jfonseca@vmware.com/g
    s/keithw\?@tungstengraphics.com/keithw@vmware.com/g
    s/michel@tungstengraphics.com/daenzer@vmware.com/g
    s/thomas-at-tungstengraphics-dot-com/thellstom-at-vmware-dot-com/
    s/zack@tungstengraphics.com/zackr@vmware.com/

    # Remove dead links
    s@Tungsten Graphics (http://www.tungstengraphics.com)@Tungsten Graphics@g

    # C string src/gallium/state_trackers/vega/api_misc.c
    s/"Tungsten Graphics, Inc"/"VMware, Inc"/
Reviewed-by: Brian Paul <brianp@vmware.com>

Every driver supports it.  All current and future Gallium drivers always
support it, and all existing classic drivers support it.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>

Every driver that enables one also enables the other.  The difference
between the two is MESA adds support for fixed-function and assembly
fragment shaders, but EXT only adds support for GLSL.  The MESA
extension was created back when Mesa did not support GLSL.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>

Limit the max glsl version level to what the state tracker supports.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

v2: Actually implement interop between the gallium
    state tracker and the VDPAU backend.

v3: Make it also available in non legacy contexts,
    fix video buffer sharing.

v4: deny interop if we don't have the same screen object

v5: rebased on upstream changes

v6: implemented VDPAUGetSurfaceivNV, improved error handling,
    unregister all surfaces in VDPAUFiniNV

v7: squash merge with Mareks changes
Signed-off-by: Christian König <christian.koenig@amd.com>

When PIPE_CAP_MIXED_FRAMEBUFFER_SIZES is not provided, parts of
ARB_framebuffer_object can't be supported, such as on NV30.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>

Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Rico Schüller <kgbricola@web.de>

Previously gl_constants::MaxVaryingComponents was used.  Now
gl_constants::VertexProgram::MaxOutputs and
gl_constants::GeometryProgram::MaxOutputs are used.

This means that st_extensions.c had to be updated to set these fields
instead of MaxVaryingComponents.  It was previously the only place that
set MaxVaryingComponents.

I believe that the structure is allocated by calloc, so the value should
be initialized to zero in non-Gallium drivers before and after my
change.  Right now nobody enables GL_ARB_geometry_shader4, so it's
pretty much dead code anyway.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Cc: Zack Rusin <zackr@vmware.com>

Now Unigine Heaven 3.0 finally works with r600g.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>

See documentation in mtypes.h.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

Reviewed-by: Brian Paul <brianp@vmware.com>

This is needed for Unigine.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>

Surprisingly all drivers supporting MSAA can already do this (r300g and r600g
for sure) and I think Christoph wanted to have this feature for his Nouveau
drivers anyway.

Any driver that supports GLSL 1.30 should be able to handle this
extension, as it's entirely implemented in the GLSL compiler.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Marek Olšák <maraeo@gmail.com>

Not needed with do_dead_builtin_varyings.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

The extension disallows elimination of set-but-unused varyings.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

See my explanation in mtypes.h.

v2: don't do this in gallium
v3: also updated the comment at the gl_shader_type definition
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

Every driver left in Mesa that enables one also enables the other.
There's no reason to let it be optional.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>

In Mesa, this extension is implemented purely in software.  Drivers may
*optionally* provide optimized paths.

NOTE: This has the side effect of enabling the extension in the radeon,
r200, and nouveau drivers.

v2: Minor whitespace tidying (suggested by Brian).
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>

This extension just provides some of the most basic software framework
for GLSL.  Without GL_ARB_vertex_shader or GL_ARB_fragment_shader,
applications still cannot use GLSL.  There's no value in
conditionalizing support for this extension.

NOTE: This has the side effect of enabling the extension in the radeon,
r200, and nouveau drivers.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>

This extension just provides some of the most basic software framework
for GLSL.  Without GL_ARB_vertex_shader or GL_ARB_fragment_shader,
applications still cannot use GLSL.  There's no value in
conditionalizing support for this extension.

NOTE: This has the side effect of enabling the extension in the radeon,
r200, and nouveau drivers.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>

Every driver left in Mesa enables this extension all the time.  There's
no reason to let it be optional.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>

Every driver left in Mesa enables this extension all the time.  There's
no reason to let it be optional.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>

Every driver left in Mesa enables this extension all the time.  There's
no reason to let it be optional.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>

Every driver left in Mesa enables this extension all the time.  There's
no reason to let it be optional.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>

We've never properly supported more than one address register.  There
isn't even a field in prog_src_register or prog_dst_register to indicate
which address register to use if RelAddr!=0.

In the state tracker, clamp MaxAddressRegs against MAX_PROGRAM_ADDRESS_REGS
since many gallium drivers do support more.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65226Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

Some Gallium drivers were crashing, because the array was not large enough.

v2: clamp the per-shader maximum in st/mesa, then sum them all up

NOTE: This is a candidate for the stable branches.

Effectively reverting the problematic hunk of
commit 614ee250