| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Set the flag automatically in gen6_emit_PIPE_CONTROL(), and set it only for
GEN6.
|
|
|
|
|
| |
Despite what the PRMs say, the driver appears to work fine when PPGTT is
disabled. But at least print a warning in that case.
|
|
|
|
| |
The code paths are not tested for a while, and have some known issues.
|
|
|
|
| |
The decode context is not thread safe.
|
|
|
|
|
| |
The winsys makes it clear that the pipe drivers should write presumed offsets.
We can always set I915_EXEC_NO_RELOC when the kernel supports it.
|
|
|
|
|
| |
It results in less code despite that i915_drm.h specifies the ring type as
part of the execution flags.
|
|
|
|
|
|
| |
The maximum batch buffer size is determined at the time of
drm_intel_bufmgr_gem_init(). Make sure the pipe driver does not exceed the
limit.
|
|
|
|
| |
Reading TIMESTAMP register may fail, depending on both kernel and hardware.
|
|
|
|
|
|
|
|
|
|
|
| |
Rename
intel_winsys_check_aperture_size() to intel_winsys_can_submit_bo(),
intel_bo_exec() to intel_winsys_submit_bo(), and
intel_winsys_decode_commands() to intel_winsys_decode_bo().
Make a semantic change to ignore intel_context when the ring is not the render
ring.
|
|
|
|
|
|
| |
The only alloc flag is INTEL_ALLOC_FOR_RENDER, which can as well be expressed
by specifying the initial write domain. The change makes it obvious that we
failed to set INTEL_ALLOC_FOR_RENDER in several places.
|
|
|
|
|
|
| |
Commit bfa8d21759c5f2b5b0885c696842167bd4c64fee uses it to work around a
hardware limitation. But there are other ways to do it without the need for
intel_bo_get_size().
|
|
|
|
| |
Make the map functions return the pointer directly.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rename
intel_bo_emit_reloc() to intel_bo_add_reloc(),
intel_bo_clear_relocs() to intel_bo_truncate_relocs(), and
intel_bo_references() to intel_bo_has_reloc().
Besides, we need intel_bo_get_offset() only to get the presumed offset afer
adding a reloc entry. Remove the function and make intel_bo_add_reloc()
return the presumed offset. While at it, switch to gem_bo->offset64 from
gem_bo->offset.
|
|
|
|
| |
It is just drm_intel_bo, but having a wrapper makes the code cleaner.
|
|
|
|
|
| |
It can be exported by drm_intel_bo_gem_export_to_prime(). The code is already
in winsys, just not enabled.
|
|
|
|
|
| |
Document the interface, and add comments as to why some features are enabled
and why some checks are made.
|
|
|
|
| |
It should be an (winsys) implementation detail.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch adds a remap table for uniforms that is used to provide a mapping
from application specified uniform location to actual location in the
UniformStorage. Existing UniformLocationBaseScale usage is removed as
table can be used to set sequential values for array uniform elements.
This mapping helps to implement GL_ARB_explicit_uniform_location so that
uniforms locations can be reorganized and handled in a more easy manner.
v2: small fixes + rename parameters for merge and split functions (Ian)
improve documentation, remove old check for location bounds (Eric)
Signed-off-by: Tapani Pälli <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
| |
Nothing uses this structure, removal fixes Klocwork error about
the possible oom condition in _mesa_symbol_table_iterator_ctor.
Signed-off-by: Tapani Pälli <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
| |
Fixes double-free with some piglit tests using geometry shaders.
Reviewed-by: Marek Olšák <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
The nvc0 bits don't appear to work, and I thought I had removed them
from the commit. Oops.
Signed-off-by: Ilia Mirkin <[email protected]>
Cc: "10.0 10.1" <[email protected]>
|
|
|
|
|
|
|
|
| |
This fixes some unwanted scaling when the output is multisampled.
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Christoph Bumiller <[email protected]>
Cc: "10.0 10.1" <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
nouveau_fence_wait has the expectation that an external entity is
holding onto the fence being waited on, not that it is merely held onto
by the current pointer. Fixes a use-after-free in nouveau_fence_wait
when used on the screen's current fence.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75279
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Christoph Bumiller <[email protected]>
Cc: "9.2 10.0 10.1" <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This logic is borrowed from the radeon code. The transfer logic will
only get called for PIPE_BUFFER resources, so it shouldn't be necessary
to worry about them becoming render targets.
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Christoph Bumiller <[email protected]>
|
|
|
|
|
|
|
| |
It's only used in this one file as far as I can tell, and exporting a
symbol named 'devices' from a shared library is a recipe for trouble.
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
| |
When building out of tree, the file ends up dangling which
may result in a binary with the old git sha.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
That structure member is a pointer, so the loop with
the Elements macro only freed up the first entry.
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
| |
v2: rebased on stale pointer fixes
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
| |
This reverts commit 67aef6dafa29fed008ea6065c425a6a92a651be9.
It caused GPU hangs. The question is why.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75900
|
|
|
|
|
| |
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
| |
After preprocessing by glcpp all adjacent spaces were replaced by
single one and glsl parser received column-shifted shader source.
It negatively affected ast location set up and produced wrong error
messages for heavily-spaced shaders.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
Reviewed-by: Carl Worth <[email protected]>
|
|
|
|
| |
Reviewed-by: Carl Worth <[email protected]>
|
|
|
|
| |
Reviewed-by: Carl Worth <[email protected]>
|
|
|
|
| |
Reviewed-by: Carl Worth <[email protected]>
|
|
|
|
| |
Reviewed-by: Carl Worth <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes this SCons build error introduced with commit
70e7905608b374f65d1f4b657f8ab61808c76ef6.
build/linux-x86_64-debug/mesa/libmesa.a(driverfuncs.os): In function `_mesa_init_driver_functions':
src/mesa/drivers/common/driverfuncs.c:99: undefined reference to `_mesa_meta_GenerateMipmap'
Signed-off-by: Vinson Lee <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I don't know how many people care about this case, but it's easy enough
to do, so we may as well. The tricky part is that for some reason Mesa
stores the number of array slices in Height, not Depth.
I thought the easiest way to handle that here was to make Height = 1
(the actual height), and srcDepth = srcImage->Height. This requires
some munging when calling _mesa_prepare_mipmap_level, so I created a
wrapper that sorts it out for us.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This is equivalent for now, and will differ once we add 1DArray support.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is largely a matter of looping over the number of slices/layers,
and not minifying depth (presumably that code exists for the unfinished
3D texture support).
Normally, I would have made the loop over array slices the outermost
loop. I suspect that would make it trickier to support 3D textures
someday, though, so I didn't. The advantage is that we would only have
one BufferData call per slice, rather than one per miplevel and slice.
However, a GenerateMipmaps microbenchmark indicates that either way is
basically just as fast. So I'm not sure it's worth bothering.
Improves performance in a GenerateMipmaps microbenchmark by nearly 5x.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
For array textures and 3D textures, this represents the layer to use.
Just pass 0 for now.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Almost the exact same code appeared twice, and it needs to expand to
handle additional texture targets. Refactor it to tidy up the code and
avoid duplicating more work in the future.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This is what the macro is for.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
fallback_required() already creates the FBO in order to check whether we
can render to the format. So it's guaranteed to exist.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This doesn't interact with the GL API, so we shouldn't use GL types.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
This was only ever used in one place; there's no reason for it to be
non-static.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Putting the implementation of each GL function in its own file makes it
much easier not to get lost.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|