Fix an off by one in the texture unit walk during texblend
setup on gen2. This caused the last enabled texunit to be
skipped resulting in totally messed up texturing.
This is a regression introduced here:
commit 1ad443ecdd
Author: Eric Anholt <eric@anholt.net>
Date: Wed Apr 23 15:35:27 2014 -0700
i915: Redo texture unit walking on i830.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
The r600 equivalent of previous commit.
v2: Correctly include the radeon winsys/radeon_common.
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Tested-by: Thomas Helland <thomashelland90 at gmail.com>
Similar to vdpau targets, we're going to convert the individual
target libraries into a single one.
The library can be built with the relevant pipe-drivers
statically linked in, or loaded as shared modules.
Currently we default to static.
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Tested-by: Thomas Helland <thomashelland90 at gmail.com>
Similar to previous commits, this allows us to minimise some
of the duplication by compacting all vdpau targets into a
single library.
v2: Include the radeon winsys only when there is a user for it.
v3: Correcly include the winsys. Now with extra brown bag :\
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Tested-by: Thomas Helland <thomashelland90 at gmail.com>
Similar to previous commit, this allows us to minimise some
of the duplication by compacting all vdpau targets into a
single library.
v2: Include the radeon winsys only when there is a user for it.
v3: Correcly include the winsys. Now with extra brown bag :\
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Tested-by: Thomas Helland <thomashelland90 at gmail.com>
Create a single library (for the vdpau api) thus reducing
the overall size of mesa. Current commit converts
vdpau-nouveau, with upcomming commits handling the rest.
The library can be built with the relevant pipe-drivers
statically linked in, or loaded as shared modules.
Currently we default to static.
Add SPLIT_TARGETS to guard the other VL targets.
Note: symlink handling is rather ugly and will need an
update to work with BSD and other non-linux platforms.
v2: Split the conversion into per-target basis.
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Tested-by: Thomas Helland <thomashelland90 at gmail.com>
Blob driver seems to need WFI in some cases after CP_EVENT_WRITE,
implying that this is asynchronous and should reset needs_wfi.
Also, CP_INVALIDATE_STATE seems to need WFI. But CP_LOAD_STATE
does not.
The blob driver also puts WFIs before writing GRAS_CL_VPORT registers.
The latter may be a work-around, as these registers should be banked/
context registers. I haven't yet found a lockup that this averts, but
I expect viewport to change infrequently so out of paranoia I will
keep these for now.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
The spec doesn't actually mention adding this, but this is the usual
pattern so I'm assuming it's a spec bug.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This extension is purely GLSL -- there are no new GL API elements.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
When the last context in a share group is destroyed, the hash table
containing all of the shader programs (ctx->Shared->ShaderObjects) is
destroyed, throwing away all of the shader programs.
Using a static variable to store program IDs ends up holding on to them
after this, so we think we still have a compiled program, when it
actually got destroyed. _mesa_UseProgram then hits GL errors, since no
program by that ID exists.
Instead, store the program IDs in the context, so we know to recompile
if our context gets destroyed and the application creates another one.
Fixes es3conform tests when run without -minfmt (where it creates
separate contexts for testing each visual).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77865
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "10.2" <mesa-stable@lists.freedesktop.org>
Prior to GLX 1.3 there was the glxMakeCurrent() function that took a
single drawable handle. The Drawable could be either a bare XID for a
Window or an XID for a glxpixmap.
GLX 1.3 added glxMakeContextCurrent that takes 2 handles: one for
reading, one for writing. Nowadays the old glxMakeCurrent call is
implemented as a call to glxMakeContextCurrent with the single handle
duplicated.
Because of this it is allowed to use a plain-old Window ID as an
argument to glxMakeContextCurrent, although nobody really documents this
sort of thing. The manpage for the NEW call specifies the arguments as
GLXPixmaps, but the actual code accepts Window XIDs too, and handles
them correctly.
Similarly, the glxSelectEvents function can also take a bare Window XID.
The "piglit" tests all use GLXWindows and/or GLXPixmaps. You never
tested swap events with a bare Window XID. That is what my app was
doing.
The swap_events code worked with Window XIDs in mesa 7.x.y. The new code
added in versions 8, 9, and 10 assumes that all buffer swap events have
a GLXPixmap associated with them. Because of the historical quirks
above, this is not true. Swap events for bare Window XIDs do NOT have a
glxpixmap resulting in a segfault.
Any app that uses the old school glxMakeCurrent call with a Window XID
while trying to use swap_events will crash when the libs try to lookup
the nonexistent GLXPixmap associated with the incoming swap event.
I believe that the people who wrote the spec overlooked this, because
the "sbc" field comes from the OML_sync extension that is defined in
terms of glxpixmaps only.
v2 (idr): Formatting changes.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54372
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
With this we can assure that mapped buffers will never change
its position when relocating the pool.
This patch should finally solve the mapping bug.
v2: Use the new is_item_in_pool util function,
as suggested by Tom Stellard
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
This function will be used when we want to map an item
that it's already in the pool.
v2: Use temporary variables to avoid so many castings in functions,
as suggested by Tom Stellard
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Acording to the OpenCL spec, it is possible to have a buffer mapped
for reading and at read from it using commands or buffers.
With this we can keep the mapping (that exists against the
temporary item) and read with a kernel (from the item we have
just added to the pool) without problems.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Now we will have a list with the items that are in the pool
(item_list) and the items that are outside it (unallocated_list)
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
These statuses will help track whether the items are mapped
or if they should be promoted to or demoted from the pool
v2: Use the new is_item_in_pool util function,
as suggested by Tom Stellard
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
This patch changes completely the way buffers are added to the
compute_memory_pool. Before this, whenever we were going to
map a buffer or write to or read from it, it would get placed
into the pool. Now, every unallocated buffer has its own
r600_resource until it is allocated in the pool.
NOTE: This patch also increase the GPU memory usage at the moment
of putting every buffer in it's place. More or less, the memory
usage is ~2x(sum of every buffer size)
v2: Cleanup
v3: Use temporary variables to avoid so many castings in functions,
as suggested by Tom Stellard
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
The intention of this pass was to give us better instruction scheduling
opportunities, but it unexpectedly reduced some instruction counts as
well:
total instructions in shared programs: 1666639 -> 1666073 (-0.03%)
instructions in affected programs: 54612 -> 54046 (-1.04%)
(and trades 4 SIMD16 programs in SS3)
Previously llvm detected cpu features automatically when the execution engine
was created (based on host cpu). This is no longer the case, which meant llvm
was then not able to emit some of the intrinsics we used as we didn't specify
any sse attributes (only on avx supporting systems this was not a problem since
despite at least some llvm versions enabling it anyway we always set this
manually). So, instead of trying to figure out which MAttrs to set just set
MCPU.
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=77493.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Tested-by: Vinson Lee <vlee@freedesktop.org>
An LLVMContext should only be accessed by a single and using the global
context was causing crashes in multi-threaded environments. Now we use
a separate context for each compile.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
CC: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Will be used to control the linking mode of pipe-drivers
in gallium targets.
Keep this hardcoded to static, as the pipe-drivers bare
an unstable interface which we do not want to expose to
the normal user.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
- gallium_pipe_loader_winsys_libs
Will be used in upcomming commits to reduce duplication
in the build.
v2: Drop the megadriver/static_target variables.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Add a couple of helpers to be used by the dri targets when
built with static pipe-drivers. Both functions provide
functionality required by the dri state-tracker.
With this patch ilo, nouveau and r300 gain support for
throttle dri configuration.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Will be used by gallium targets that statically link the
pipe-drivers in the final library. Provides identical
functionality to device_descriptor.create_screan.
v2:
- Don't sw_screen_wrap the i915/svga screen.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
If memory serves me right, at least one debug wrapper does
not return the base screen on failure.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Required for the dri state-tracker. Will be used to retrieve
driver specific configuration parameters:
- share_fd (dmabuf) capability
- throttle
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Ville Syrjälä
Iago Toral Quiroga
Emil Velikov
Chris Forbes
Rob Clark
Kenneth Graunke
Aaron Watry
Daniel Manjarres
Bruno Jiménez
Matt Turner
Francisco Jerez
Roland Scheidegger
Tom Stellard
Michel Dänzer