| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Merge the code with gen6+ 3DSTATE_GS, and delete brw_gs_state.c,
together with brw_gs_unit_state.
Signed-off-by: Rafael Antognolli <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since we always call brw_batch_emit anyways, we can hopefully make things
simpler by calling it only once, and then branching inside its body. This
can be helpful when bringing the gen4-5 code into this function.
Additionally, check for GEN_GEN == 6 instead of < 7 in cases that won't apply
to lower gens.
Signed-off-by: Rafael Antognolli <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This function only emits a particular case of 3DSTATE_GS. Instead, we can do
that inside genX(upload_gs_state), and later reuse part of that code for
emitting gen4-5 state.
There's the additional benefit of allowing us to remove gen6_gs_state.c, which
was only left because of this function.
Signed-off-by: Rafael Antognolli <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
It's a very simple conversion, and it allows us to delete brw_cc.c.
Signed-off-by: Rafael Antognolli <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use set_blend_entry_bits and set_depth_stencil_bits to fill most of the
color calc struct, and then manually update the rest.
v2:
- Always check for depth_irb (Ken)
- Always set Backface Stencil Ref (Ken)
- Always set alpha reference value (Ken)
Signed-off-by: Rafael Antognolli <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
This makes the code more consistent accross generations.
Signed-off-by: Rafael Antognolli <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gen6+ uses _mesa_base_format_has_channel() to check for the alpha
channel, while gen4-5 use ctx->DrawBuffer->Visual.alphaBits. By using
_mesa_base_format_has_channel() here we keep the same behavior accross
all gen.
While initially both ways of checking the alpha channel seemed correct
to me, this change also seems to fix fbo-blending-formats piglit test on
gen4.
Signed-off-by: Rafael Antognolli <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Add a helper function to reuse code that fills blend entry related
state, and make genX(upload_blend_state) use it. This function can later
be used by gen4-5 color calc state to set the blend related bits.
Signed-off-by: Rafael Antognolli <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Gen4-5 basically glue DEPTH_STENCIL_STATE, COLOR_CALC_STATE, and
BLEND_STATE together into a single COLOR_CALC_STATE structure.
By making a helper function, we'll be able to reuse it when filling
out Gen4-5 COLOR_CALC_STATE without replicating any actual logic.
We use generation-defined typedef to handle the polymorphism.
Reviewed-by: Rafael Antognolli <[email protected]>
|
|
|
|
|
|
| |
CID: 1250585
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
| |
Check that irb isn't NULL before accessing irb->Base.Base.NumSamples.
CID: 1026046
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
| |
The NULL check might fail if offset isn't 0.
CID: 971379
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's a bit rare, but blorp can trigger a urb reconfiguration. When
that happens, we need to re-upload the URB config. Previoulsy blorp
would set BRW_NEW_URB_SIZE, but this is a pretty big hammer as it
would cause back-to-black blorp operations to reconfigure both times.
Using BRW_NEW_BLORP is a small, more accurate hammer.
v2 (idr): Sort BRW_NEW_ tokens to match brw_recalculate_urb_fence and
gen6_urb.
v3 (idr): Don't whack BRW_NEW_URB_SIZE in blorp. Suggested by Jason.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
Fixes dEQP-GLES31.functional.debug.negative_coverage.get_error.shader.srgb_decode_samplerparameter{f,fv,i,Iiv,Iuiv,iv}.
Reviewed-by: Jason Ekstrand <[email protected]>
Reviewed-by: Iago Toral Quiroga <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
st_framebuffer_create returns NULL if stfbi == NULL or
st_framebuffer_add_renderbuffer returns false for the colour buffer.
Fixes Xorg crashing on startup using glamor on radeonsi.
Fixes: 147d7fb772a7 ("st/mesa: add a winsys buffers list in st_context")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101775
Signed-off-by: Michel Dänzer <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
It's no longer used.
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
| |
Any form of CCS on gen9+ only works on Y-tiled images. The only caller
of create_for_bo which uses Y-tiled BOs is create_for_dri_image.
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
We want to start using create_for_dri_image for all miptrees created
from __DRIimage, including those which come from a window system. In
order to allow for fast clears to still work on window system buffers,
we need to allow for creating aux surfaces.
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
| |
The __DRI_FORMAT enums are all UNORM but we will frequently want sRGB
when creating miptrees for renderbuffers. This lets us specify.
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
| |
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to the wonders of autogeneration, this new version covers a few
formats that the old version was missing:
MESA_FORMAT_SRGB8_ALPHA8_ASTC_3x3x3
MESA_FORMAT_SRGB8_ALPHA8_ASTC_4x3x3
MESA_FORMAT_SRGB8_ALPHA8_ASTC_4x4x3
MESA_FORMAT_SRGB8_ALPHA8_ASTC_4x4x4
MESA_FORMAT_SRGB8_ALPHA8_ASTC_5x4x4
MESA_FORMAT_SRGB8_ALPHA8_ASTC_5x5x4
MESA_FORMAT_SRGB8_ALPHA8_ASTC_5x5x5
MESA_FORMAT_SRGB8_ALPHA8_ASTC_6x5x5
MESA_FORMAT_SRGB8_ALPHA8_ASTC_6x6x5
MESA_FORMAT_SRGB8_ALPHA8_ASTC_6x6x6
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Later commits require intel_update_image_buffer() to have control over
the miptree creation. However, intel_update_winsys_renderbuffer_miptree()
currently creates it based on the given buffer object. This patch moves
the creation to the caller side.
Signed-off-by: Ben Widawsky <[email protected]>
Acked-by: Daniel Stone <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is nothing particularly useful to do currently if the update
fails, but there is no point carrying on either. As a result, this has a
behavior change.
v2: Make the return type a bool (Topi)
v3: Don't leak the bo if update_winsys_renderbuffer fails. (Jason)
Signed-off-by: Ben Widawsky <[email protected]>
Acked-by: Daniel Stone <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]> (v2)
Reviewed-by: Jason Ekstrand <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This does make a tiny functional change in that we now also test for
whether or not the format supports texturing and not just rendering.
However, this should have no practical effect as all renderbuffers use
texturable formats.
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
| |
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is what we do in intel_image_target_renderbuffer_storage and it
makes more sense than stomping them. Because the image gets created as
a 2D image with one miplevel, they should already be equal to the
provided width/height. Adding the tile offset makes some sense
depending on how you interpret the fields.
The only place these fields are used for in state setup is to set up the
image parameters we pass into shaders. There may be issues here if you
try to use image_load_store on something pulled in from EGL but that's
probably broken already. This just makes it consistently broken.
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Chad Versace <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
This is mostly a direct port. The only bit of refactoring that was done
was to make creating a planar miptree be an early return from the
non-planar case. Alternatively, we could have three functions: two
helpers and a main function to just call the right helper. Making the
planar case an early return seemed cleaner.
Reviewed-by: Chad Versace <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit a5e733c6b52e93de3000647d075f5ca2f55fcb71 fixes the dangling
framebuffer object by unreferencing the window system draw/read buffers
when context is released. However this can prematurely destroy the
resources associated with these window system buffers. The problem is
reproducible with Turbine Demo running with VMware driver. In this case,
the depth buffer content was lost when the context is rebound to a
drawable.
To prevent premature destroy of the resources associated with
window system buffers, this patch maintains a list of these buffers in
the context, making sure the reference counts of these buffers will not
reach zero until the associated framebuffer interface objects no
longer exist. This also helps to avoid unnecessary destruction and
re-construction of the resources associated with the framebuffer.
Fixes VMware bug 1909807.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
The locking was supposed to go away in commit 314647c4c206917ec01b7
(i965: Drop global bufmgr lock from brw_bo_map_* functions.), but
this lone unlock remains.
I'm guessing I messed this up when splitting up Chris's patch.
Reviewed-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
I want to remove vc4's dependency on headers from libdrm as well, but
storing multiple copies of drm_fourcc.h in our tree would be silly.
v2: Update Android.mk as well, move distcheck drm*.h references to
top-level noinst_HEADERS.
Reviewed-by: Lionel Landwerlin <[email protected]> (v1)
Reviewed-by: Daniel Stone <[email protected]> (v1)
Reviewed-by: Rob Herring <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Valgrind doesn't actually implement VALGRIND_FREELIKE_BLOCK as the
exact inverse of VALGRIND_MALLOCLIKE_BLOCK. It makes the block
inaccessible, but still leaves it defined in its allocation tracker i.e.
it will report the mmap as lost despite the call to FREELIKE!
Instead of treating the mmap as an allocation, treat it as changing the
access bits upon the memory, i.e. that it becomes defined (because of
the buffer objects always contain valid content from the user's
perspective) upon mmap and inaccessible upon munmap. This makes memcheck
happy without leaving it thinking there is a very large leak.
Finally for consistency, we treat all the mmap/munmap paths the same
even though valgrind can intercept the regular mmap used for GTT. We
could move this in the drm_mmap/drm_munmap macros, but that quickly
looks ugly given the desire for those to support different OSes, but I
didn't try that hard!
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using a read-only CPU mapping, we may encounter stale buffer
contents. For example, the Piglit primitive-restart test offers the
following scenario:
1. Read data via a CPU map.
2. Destroy that buffer.
3. Create a new buffer - obtaining the same one via the BO cache.
4. Call BufferSubData, which does a GTT map with MAP_WRITE | MAP_ASYNC.
(We avoid set_domain for async mappings, so no flushing occurs.)
5. Read data via a CPU map.
(Without explicit clflushing, this will contain data from step 1!)
Otherwise, everything ought to work, keeping in mind that we never use
CPU maps for writing - just read-only CPU maps.
This restores the performance gains after Matt's revert in commit
71651b3139c501f50e6547c21a1cdb816b0a9dde.
v2: Do the invalidate later, and even when asking for a brand new map.
v3: Add more comments from Chris.
Reviewed-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just map the buffer and memcpy. This will do a CPU mmap, which should
be reasonably efficient, and doing this gives us full control over the
domains and caching instead of leaving it to the kernel.
This prevents regressions on Braswell in the next commit. Specifically
GL45-CTS.shader_atomic_counters.basic-buffer-operations. Because async
maps start skipping set-domain, the pread thought everything was nicely
still in the CPU domain, and returned stale data.
v2: Use _mesa_error_no_memory() if the map fails instead of crashing.
Reviewed-by: Chris Wilson <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Ben Widawsky <[email protected]>
|
|
|
|
|
|
|
|
| |
Reduces IOCTL calls by 1, and provides a centralized place to override
such configurations if we have a need to do so.
Signed-off-by: Ben Widawsky <[email protected]>
Reviewed-by: Lionel Landwerlin <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From KHR_fence_sync:
When the condition of the sync object is satisfied by the fence
command, the sync is signaled by the associated client API context,
causing any eglClientWaitSyncKHR commands (see below) blocking on
<sync> to unblock. The only condition currently supported is
EGL_SYNC_PRIOR_COMMANDS_COMPLETE_KHR, which is satisfied by
completion of the fence command corresponding to the sync object,
and all preceding commands in the associated client API context's
command stream. The sync object will not be signaled until all
effects from these commands on the client API's internal and
framebuffer state are fully realized. No other state is affected by
execution of the fence command.
If clients are passing the fence fd (from EGL_ANDROID_native_fence_sync)
to a compositor, that fence must only be signaled once the framebuffer
is resolved and not before as is currently the case.
v2: fixup assert to use GL_SYNC_GPU_COMMANDS_COMPLETE (Chad)
Reported-by: Sergi Granell <[email protected]>
Fixes: c636284ee8ee ("i965/sync: Implement DRI2_Fence extension")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Sergi Granell <[email protected]>
Cc: Rob Clark <[email protected]>
Cc: Chad Versace <[email protected]>
Cc: Daniel Stone <[email protected]>
Cc: Kenneth Graunke <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Using CPU maps of non-coherent buffers can get us in a lot of trouble,
and WC maps are a reasonable alternative anyway. Guard against shooting
ourselves in the foot by adding an assert, and comment.
Reviewed-by: Chris Wilson <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the user triggers an implicit batch flush while holding access to a
CPU mapped buffer, that mmapping will be invalidated by the kernel for
non-LLC devices. (The kernel when executing a batch will change the
cache domain of the buffers in that batch, which for non-LLC CPU access
will cause that buffer to be clflushed and any further CPU access to be
discarded.) To prevent this, simply disallow any CPU async mmap access.
The cases where async CPU access to a non-LLC buffer should continue to
be allowed via their preferred snooping path.
v2 (Ken): Reword the comment slightly.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the buffer is being shared with an external client, our own state
tracking may be stale and in some cases we may wish to double check with
the kernel/hw state. At the moment, this is synonymous with not being
reusable, but the semantics between reusable and external are quite
different and we will have more examples of non-reusable buffers in the
near future.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
| |
It can't parse "llu".
Reviewed-by: Thomas Helland <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, we use set_domain() to cause a stall on rendering. But the
set-domain ioctl has the side-effect of changing the kernel's cache
domain underneath the struct_mutex, which may perturb state if there was
no rendering to wait upon and in general is much heavier than the
lockless wait-ioctl. Historically libdrm used set-domain as we did not
have an explicit wait-ioctl (and the patches to teach it to use wait if
available were lost in the mists). Since mesa already depends upon a
kernel support the wait-ioctl, we do not need to supply a fallback.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By design pixel shaders can have up to 3 variants:
* The standard one.
* glDrawPixels variant.
* glBitmap variant.
However "shader_has_one_variant" ignores this fact, and therefore
st_update_fp would select the wrong variant if glDrawPixels or glBitmap
was ever called.
This patch fixes the problem. If the standard variant has been created,
calling glDrawPixels or glBitmap will append the variant to the second
entry of the linked list, so that st_update_fp still selects the right
one if shader_has_one_variant is set.
If the standard variant hasn't been created yet and glDrawPixel/Bitmap
has been called, st_update_fp will will see this and take the slow path
instead. The standard variant will then be added at the front of the
linked list, so that the next time the fast path is taken.
Blender in particular is hit by this bug.
v2: Marek - cosmetic changes
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=101596
Signed-off-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we try to build a display list with just a glPrimitiveRestartNV()
call, we'd crash because of a null GLvertexformat::PrimitiveRestartNV
pointer. This change fixes that case.
The previous patch fixed the case of calling glPrimitiveRestartNV()
inside a glBegin/End pair.
v2: minor clean-up in save_PrimitiveRestartNV(), per Charmaine.
Reviewed-by: Charmaine Lee <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
glPrimitiveRestartNV crashes when it is called during the compilation
of a display list.
There are two reasons:
- ctx->Driver.CurrentSavePrimitive is not set to the current primitive
- save_PrimitiveRestartNV() calls _save_Begin() which only sets an
OpenGL error, instead of calling vbo_save_NotifyBegin().
This patch correctly calls vbo_save_NotifyBegin() but it detects
the current primitive mode by looking at the latest saved primitive.
Additional work by Brian Paul
Signed-off-by: Olivier Lauffenburger <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101464
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Charmaine Lee <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Charmaine Lee <[email protected]>
|