GEN10_FLOAT_BLEND_OPTIMIZATION_ENABLE);
>
Yep, looks like the default is still off for some reason.
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-
t;= 9;
>
> switch (screen->devinfo.gen) {
> + case 11:
> case 10:
> case 9:
> case 8:
>
There's some stuff missing, but this is the level of support we want to
advertise when everything's said and done, so I
brw_batch_emit(brw, GENX(3DSTATE_DS), ds);
> } else {
> + assert(devinfo->gen < 11 ||
> + vue_prog_data->dispatch_mode == DISPATCH_MODE_SIMD8);
> +
assert(GEN_GEN < 11 || ...)
(no need for run-time devinfo access)
With those changed,
Reviewed
-)
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
color) {
>/* Updating a surface state object may require that the state cache be
> * invalidated. From the SKL PRM, Shared Functions -> State -> State
>
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digitally signed message part.
___
ISL_DEV_GEN(dev) == 10) {
I'd just do:
} else if (ISL_DEV_GEN(dev) < 11) {
Reviewed-by: Kenneth Graunke
>/* From the Skylake PRM Vol 5, Maximum Surface Size in Bytes:
> *"In addition to restrictions on maximum height, width, and depth,
>
t;info.gen == 10) {
> - intel_logw("Cannonlake Vulkan support is alpha");
> + } else if (device->info.gen >= 8 && device->info.gen <= 10) {
> + /* Broadwell, Cherryview, Skylake, Broxton, Kabylake, Coffelake,
> + * Cannonlake is as fully supported as
> break;
> case I915_PARAM_CMD_PARSER_VERSION:
> *getparam->value = 9;
>
This patch is:
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
The kernel used to have execbuf parameters to program the INSTPM bit
for whether 3DSTATE_CONSTANT_* should be relative to dynamic state
base address or an absolute address. However, they never worked in
the presence of hardware contexts, so I deleted them a while back.
It doesn't make sense to se
You fixed this but accidentally squashed
it into the next patch instead of this one.
> + view.swizzle = ISL_SWIZZLE_IDENTITY;
> +
>if (obj->Target == GL_TEXTURE_CUBE_MAP ||
>obj->Target == GL_TEXTURE_CUBE_MAP_ARRAY)
> view.usage |=
On Wednesday, February 7, 2018 1:21:53 PM PST Anuj Phogat wrote:
> On Wed, Feb 7, 2018 at 12:24 PM, Francisco Jerez wrote:
> > Anuj Phogat writes:
> > > On Wed, Feb 7, 2018 at 11:55 AM, Francisco Jerez wrote:
> > > > You can also just drop the patch, unless you want to change the
> > > > front-end
On Tuesday, February 6, 2018 4:38:00 PM PST Nanley Chery wrote:
> On Mon, Feb 05, 2018 at 04:08:40PM -0800, Anuj Phogat wrote:
> > Signed-off-by: Anuj Phogat
> > ---
> > src/mesa/drivers/dri/i965/genX_state_upload.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a
On Tuesday, February 6, 2018 5:09:10 PM PST Anuj Phogat wrote:
> From Message Descriptor section in gfxspecs:
> "Memory fence messages without Commit Enable set do not return
> anything to the thread (response length is 0 and destination
> register is null)."
>
> It fixes a piglit GPU hang in
On Thursday, January 25, 2018 3:29:01 AM PST Emil Velikov wrote:
> On 18 January 2018 at 07:36, Kenneth Graunke wrote:
> > Growing the batch/state buffer is a lot more dangerous than I thought.
> >
> > A number of places emit multiple state buffer sections, and then write
>
this could cause a GPU hang.
>
> This issue probably is not disk shader cache specific, but rather may
> have been hidden since the compiler would take some time to recompile
> programs after the cache was cleared.
>
> Cc: Kenneth Graunke
> Signed-off-by: Jordan Justen
> ---
&
this could cause a GPU hang.
>
> This issue probably is not disk shader cache specific, but rather may
> have been hidden since the compiler would take some time to recompile
> programs after the cache was cleared.
>
> Cc: Kenneth Graunke
> Signed-off-by: Jordan Justen
> ---
&
On Friday, February 2, 2018 5:07:00 PM PST Jordan Justen wrote:
> Signed-off-by: Jordan Justen
> ---
> src/mesa/drivers/dri/i965/brw_program_cache.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_program_cache.c
> b/src/mesa/drivers/
le of wrongly tabbed indents.
>
> Cc: Alejandro Piñeiro
> Cc: Kenneth Graunke
> Signed-off-by: Andres Gomez
> ---
> src/mesa/drivers/dri/i965/genX_state_upload.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
Thanks!
Reviewed-by: Kenneth Graunk
In commit 3f353342a6b6744773c26ed66b12afed42bd57af (present in 17.3.0)
we started unconditionally using I915_EXEC_NO_RELOC, which was
introduced in Linux v3.9. ChromeOS kernel 3.8 has backported this,
so it should work too.
Running on older kernels would likely result in every single batch
being
batch buffer ends, since we know those BO's are not around anymore.
>
> This change fixes GPU hangs on CNL. The (partial) solution to this
> problem so far was to entirely disable push constants on this platform.
>
> Signed-off-by: Rafael Antognolli
> Cc: Kenneth Graunke
g surface. Sampling
from that slice will also go to the underlying surface. But, sampling
from other slices will still get compression, which is actually better.
Patch 6 is also good...it'll make us only resolve the slice bound for
rendering, and not all the slices bound for textur
L_ALPHA32F_ARB:
>return ctx->API == API_OPENGL_COMPAT &&
>
Seems straightforward enough :)
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
rectly.
>
> This little series fixes all of the issues I've seen while trolling through
> the code trying to fix CCS-related hangs. Hopefully, we'll see fewer of
> them in future.
>
> Cc: Kenneth Graunke
>
> Jason Ekstrand (4):
> i965/miptree: Take a
On Wednesday, January 24, 2018 2:03:41 AM PST Jason Ekstrand wrote:
> Instead of keeping an array of booleans, we now hang onto an array of
> isl_aux_usage enums. This means that the thing we are passing from
> brw_draw.c to surface state setup is the thing that surface state setup
> actually need
On Tuesday, January 23, 2018 1:32:53 AM PST Chris Wilson wrote:
> Quoting Kenneth Graunke (2018-01-23 09:28:20)
> > The purpose of the workaround BO is to write to it.
>
> Do you care for the serialisation here? I thought the purpose of the wa
> was just for write-only memor
On Tuesday, January 23, 2018 10:34:25 AM PST Dylan Baker wrote:
> There's a bug in our meson build, and I sent a patch. We need to join_dirs
> with
> get_option('prefix'). I got a little confused because when you pass a relative
> directory to meson's `install` option it will autotmatically make i
On Tuesday, January 23, 2018 3:31:23 AM PST Marc Dietrich wrote:
> Hi Dylan,
>
> running "Heaven" fails with "error: #extension directive is not allowed in
> the
> middle of a shader" because drirc (which contains an exception for this
> program) is somehow not read in meson builds.
>
> Marc
The purpose of the workaround BO is to write to it.
---
src/mesa/drivers/dri/i965/genX_blorp_exec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
index 062171af600..237ab876abe 100644
--- a/src/mesa/dr
On Thursday, January 18, 2018 11:47:33 PM PST Iago Toral wrote:
> On Thu, 2018-01-18 at 15:49 -0800, Kenneth Graunke wrote:
> > We have to start render targets at binding table index 0 in order to
> > use
> > headerless FB write messages, and in fact already assume this
On Thursday, January 18, 2018 1:44:47 PM PST Chuck Atkins wrote:
> Is there a logging infrastructure currently available to drivers in Mesa?
> I was looking to clean up some of swr's debug / info output and have it
> conditional on the MESA_DEBUG and LIBGL_DEBUG variables but then I realized
> that
"as a shader image");
> + if (rendering) {
> + intel_disable_rb_aux_buffer(brw, tex_obj->mt, 0, ~0,
> + "as a shader image");
> + }
>
>
l_gt1, "Intel(R) HD Graphics (Coffeelake 2x6 GT1)")
> CHIPSET(0x3E99, cfl_gt1, "Intel(R) HD Graphics (Coffeelake 2x6 GT1)")
>
I haven't verified these but it seems like a good idea to update them.
Acked-by: Kenneth Graunke
signature.asc
Description: This is a
On Thursday, January 18, 2018 7:05:46 PM PST Jason Ekstrand wrote:
> On Thu, Jan 18, 2018 at 4:30 PM, Kenneth Graunke
> wrote:
>
> > On Friday, January 12, 2018 1:28:00 AM PST Chris Wilson wrote:
> > > Quoting Jason Ekstrand (2018-01-12 01:40:52)
> > > > Thi
We have to start render targets at binding table index 0 in order to use
headerless FB write messages, and in fact already assume this in a bunch
of places in the code. Let's finish that off, and not bother storing 0
in a struct to pretend to add it in a few places.
---
src/intel/blorp/blorp.c
On Friday, January 12, 2018 1:28:00 AM PST Chris Wilson wrote:
> Quoting Jason Ekstrand (2018-01-12 01:40:52)
> > This helper should be used carefully as setting tiling is a racy
> > operation since it potentially interacts with other processes. Still,
> > it is a useful thing to be able to do.
>
> else float(args.after[k][m] - args.before[k][m]) / args.before[k][m])
> +for p in hurt:
> +namestr = p[0] + " " + p[1]
> + print(m + " HURT: " + get_result_string(
> +namestr, args.before[p][m], args.
'aux' is a very generic name, suggesting it can be a bunch of things.
However, it's always the brw_*_prog_data structure. So, call it that.
---
src/mesa/drivers/dri/i965/brw_program_cache.c | 31 ++-
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/src/mesa/
On Thursday, January 11, 2018 5:40:50 PM PST Jason Ekstrand wrote:
> From: Jason Ekstrand
>
> Otherwise, create_for_bo will just grab the tiling from the BO which is
> not what we want when using modifiers.
>
> Cc: mesa-sta...@lists.freedesktop.org
Patches 1-2 are:
Reviewed-b
We want both anyway, but this will simplify things a tiny bit in an
upcoming patch.
---
src/mesa/drivers/dri/i965/intel_tex_validate.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_tex_validate.c
b/src/mesa/drivers/dri/i965/intel_tex_val
I want to use compute_num_levels inside i965. Rather than duplicating
it, move it from mesa/st to core Mesa, and make it non-static.
---
src/mesa/main/mipmap.c | 24
src/mesa/main/mipmap.h | 4
src/mesa/state_tracker/st_gen_mipmap.c |
This requires moving the _MaxLevel handling up to the callers. Another
user of intel_finalize_mipmap_tree will be added later that depends on
_MaxLevel not being modified.
---
src/mesa/drivers/dri/i965/intel_tex.h | 3 ++-
src/mesa/drivers/dri/i965/intel_tex_validate.c | 30
Meta is awful and we'd like to stop using it. Implementing this using
BLORP allows us to stop trashing a bunch of GL state every time.
This follows the structure of st_generate_mipmap().
compute_num_levels is lifted directly from there.
Improves performance in Gl41HdrBloom by about 11.794% +/- 1
Growing the batch/state buffer is a lot more dangerous than I thought.
A number of places emit multiple state buffer sections, and then write
data to the returned pointer, or save a pointer to brw->batch.state.bo
and then use it in relocations. If each call can grow, this can result
in stale map
@ tag is not recommended.
>
> +
> +If you are not the author of the original patch, please Cc: them in your
> +nomination request.
> +
>
>
> The stable tag
>
That seems like reasonable advice.
Reviewed-by: Kenneth Graunke
ko
> Cc: Tvrtko Ursulin
> Cc: Lionel Landwerlin
Thanks Chris!
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Portal 2 appears to bind RGBA_UNORM textures to a sampler2DShadow,
and calls shadow2D() on it. This causes undefined behavior in OpenGL.
Unfortunately, our sampler appears to hang in this scenario, which is
not acceptable. Just give them a null surface instead, which returns
all zeroes.
Fix
On Wednesday, January 17, 2018 4:00:26 AM PST Nicolai Hähnle wrote:
> On 17.01.2018 01:23, Jordan Justen wrote:
> > On 2018-01-16 13:57:37, Kenneth Graunke wrote:
> >> On Tuesday, January 16, 2018 11:18:13 AM PST Emil Velikov wrote:
> >>> Hi all,
> >>>
&g
em_create_from_name(screen->bufmgr, name, handle);
> + buffer = drm_intel_bo_gem_create_from_name(screen->bufmgr, name, handle);
> if (buffer == NULL)
>return NULL;
> ret = drm_intel_bo_get_tiling(buffer, &tiling, &bit_6_swizzle);
>
Thanks! I dropped all these for i96
On Tuesday, January 16, 2018 4:21:57 PM PST Kenneth Graunke wrote:
> On Wednesday, January 10, 2018 11:22:39 AM PST Jason Ekstrand wrote:
> > ---
> > src/mesa/drivers/dri/i965/brw_draw.c | 41
> >
> > 1 file changed, 41 insertions(+
> should never end up in the depth cache. However, this does complete the
> flush/add_bo pair for regular drawing which will be required for the next
> commit.
With this new commit message,
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digita
gt; + if (!format_ccs_e_compat_with_miptree(&brw->screen->devinfo,
> + mt, view_format)) {
>perf_debug("Incompatible sampling format (%s) for rbc (%s)\n",
> isl_format_get_layout(view_format)->name,
> _
On Wednesday, January 10, 2018 11:22:39 AM PST Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_draw.c | 41
>
> 1 file changed, 41 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
> b/src/mesa/drivers/dri/i965/brw_draw.c
> inde
w, bo);
> }
>
> void
> -brw_render_cache_add_bo(struct brw_context *brw, struct brw_bo *bo)
> +brw_render_cache_add_bo(struct brw_context *brw, struct brw_bo *bo,
> +enum isl_format format,
> +enum isl_aux_usage aux_usage)
> {
* formats. However, there are issues with blending where it doesn't
> * properly apply the sRGB curve to the clear color when blending.
> */
> - if (blend_enabled && isl_format_is_srgb(render_format) &&
> +
---
> src/mesa/drivers/dri/i965/gen7_sol_state.c | 6 +---
> 3 files changed, 58 insertions(+), 39 deletions(-)
Series is:
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing lis
On Tuesday, January 16, 2018 11:18:13 AM PST Emil Velikov wrote:
> Hi all,
>
> As you've know the Mesa 18.0.0 release plan has been available for a while
> on the mesa3d.org website [1].
>
> In case you've missed it here it is:
>
> Jan 19 2018 - Feature freeze/Release candidate 1
> Jan 26 2018
On Thursday, January 11, 2018 1:53:48 AM PST Thomas Hellstrom wrote:
> Upon reception of an event that lowered the number of active back buffers,
> the code would immediately try to free all back buffers with an id equal to or
> higher than the new number of active back buffers.
>
> However, that
On Wednesday, January 10, 2018 5:11:21 AM PST Iago Toral wrote:
> On Mon, 2018-01-08 at 13:30 -0800, Kenneth Graunke wrote:
> > Growing the batch/state buffer is a lot more dangerous than I
> > thought.
> >
> > A number of places emit multiple state buffer sections, and
On Monday, January 8, 2018 3:00:30 PM PST Rafael Antognolli wrote:
> On Thu, Jan 04, 2018 at 11:36:48AM -0800, Kenneth Graunke wrote:
> > Apparently, Geminilake requires you to whack a chicken bit to select
> > either compute or tessellation mode for barriers. The recommendation
&
Cleaner.
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 877f68ee7cf..b4fcd92b6bd 100644
--- a/src/mesa/d
Having a boolean for "we're using malloc'd shadow copies for all
buffers" is cleaner than having a cpu_map pointer for each. It was
okay when we had one buffer, but this is more obvious.
---
src/mesa/drivers/dri/i965/brw_context.h | 2 +-
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 39
Growing the batch/state buffer is a lot more dangerous than I thought.
A number of places emit multiple state buffer sections, and then write
data to the returned pointer, or save a pointer to brw->batch.state.bo
and then use it in relocations. If each call can grow, this can result
in stale map
Now that we have two of these, we're duplicating a bunch of this logic.
The next commit will add more logic, which would make the duplication
seem worse.
This ends up setting EXEC_OBJECT_CAPTURE on the batch, which isn't
necessary (it's already captured), but it should be harmless.
---
src/mesa/d
This will make aubinator_error_decode decode them properly.
---
src/intel/genxml/gen10.xml | 2 ++
src/intel/genxml/gen75.xml | 2 ++
src/intel/genxml/gen8.xml | 2 ++
src/intel/genxml/gen9.xml | 2 ++
4 files changed, 8 insertions(+)
diff --git a/src/intel/genxml/gen10.xml b/src/intel/genxml/g
On Saturday, January 6, 2018 9:07:44 PM PST Jason Ekstrand wrote:
> On Sat, Jan 6, 2018 at 5:12 PM, Kenneth Graunke
> wrote:
>
> > On Wednesday, November 15, 2017 11:53:08 PM PST Iago Toral Quiroga wrote:
> > > We currently handle this by lowering it to a uniform for ge
I'd really rather
see it converted to a uniform, like it is in the normal GLSL paths. If
you're going to add recompiles based on the key like this, it might be
nice to at least update the brw_tcs_precompile function to guess, so we
at least attem
intel_batchbuffer_emit_float is dead code, it should go.
intel_batchbuffer_emit_dword only had one user, which had bungled using
them by forgetting to call intel_batchbuffer_require_space first. So it
seems wise to delete these unsafe helpers.
Cc: mesa-sta...@lists.freedesktop.org
---
src/mesa/
intel_batchbuffer_emit_dword doesn't reserve space for the DWord it
emits. In the past, we had some reserved batch space to ensure this
worked. With the switch to growing batches, we need to actually request
space so that we grow if necessary.
Fixes: 2c46a67b4138631217141f (i965: Delete BATCH_RE
On Thursday, January 4, 2018 11:56:44 AM PST Jason Ekstrand wrote:
> On January 4, 2018 12:51:15 Karol Herbst wrote:
>
> > On Thu, Jan 4, 2018 at 7:06 PM, Ilia Mirkin wrote:
> >> On Thu, Jan 4, 2018 at 10:01 AM, Karol Herbst wrote:
> >>> significant changes to last series:
> >>> * arb_gpu_shade
Growing the batch/state buffer is a lot more dangerous than I thought.
A number of places emit multiple state buffer sections, and then write
data to the returned pointer, or save a pointer to brw->batch.state.bo
and then use it in relocations. If each call can grow, this can result
in stale map
Uncommenting these blocks stress tests the batch/state growth code by
trying to "grow" a buffer to the same size at least once per batch.
When anything goes wrong with this code, dumping the validation list
is a useful way to figure out what's happening.
---
src/mesa/drivers/dri/i965/intel_batchb
Apparently, Geminilake requires you to whack a chicken bit to select
either compute or tessellation mode for barriers. The recommendation
is to switch between them at PIPELINE_SELECT time.
We may not need to do this all the time, but I don't know that it hurts
either. PIPELINE_SELECT is already
These are the same, we don't need a separate opcode enum per backend.
---
src/intel/compiler/brw_eu_defines.h | 5 ++---
src/intel/compiler/brw_fs.cpp | 2 +-
src/intel/compiler/brw_fs_generator.cpp | 2 +-
src/intel/compiler/brw_fs_nir.cpp | 2 +-
src/intel/compiler/br
On Friday, December 29, 2017 2:48:13 PM PST Eric Anholt wrote:
> Kenneth Graunke writes:
>
> > [ Unknown signature status ]
> > On Thursday, December 28, 2017 5:56:18 PM PST Eric Anholt wrote:
> >> For VC5, the shader needs to have the appropriate base type for the
name);
> + rt_var->data.location = FRAG_RESULT_DATA0 + i;
> +
> + state.rt_var[state.num_rt_vars++] = rt_var;
> + }
> +
> + nir_foreach_function(function, shader) {
> + if (function->impl) {
> + nir_builder_init(&state.b, functio
On Wednesday, December 27, 2017 3:13:42 PM PST Jason Ekstrand wrote:
> On December 27, 2017 17:06:43 Kenneth Graunke wrote:
>
> > On Wednesday, December 27, 2017 12:58:12 PM PST Jason Ekstrand wrote:
> >> ---
> >> src/intel/tools/aubinator_error_decode.c | 6
On Wednesday, December 27, 2017 12:58:12 PM PST Jason Ekstrand wrote:
> ---
> src/intel/tools/aubinator_error_decode.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/intel/tools/aubinator_error_decode.c
> b/src/intel/tools/aubinator_error_decode.c
> index d6fb
On Tuesday, December 26, 2017 1:22:25 PM PST Rob Clark wrote:
> On Mon, Dec 25, 2017 at 10:22 PM, Kenneth Graunke
> wrote:
> > On Monday, December 25, 2017 12:19:49 PM PST Rob Clark wrote:
> >> For GL_ARB_compute_variable_group_size
> >>
> >> Reported-by
On Tuesday, December 26, 2017 6:30:39 AM PST Jason Ekstrand wrote:
> Yes, please!
>
> Reviewed-by: Jason Ekstrand
>
> Might be worth an ack from idr.
Yep, would be good. Could I trouble you for a review on the Piglit
patch which needs to land before this one?
https://lists.freedesktop.org/arc
Older OpenGL defines two equations for converting from signed-normalized
to floating point data. These are:
f = (2c + 1)/(2^b - 1)(equation 2.2)
f = max{c/2^(b-1) - 1), -1.0} (equation 2.3)
Both OpenGL 4.2+ and OpenGL ES 3.0+ mandate that equation 2.3 is to be
use
On Monday, December 25, 2017 12:19:49 PM PST Rob Clark wrote:
> For GL_ARB_compute_variable_group_size
>
> Reported-by: Karol Herbst
> Signed-off-by: Rob Clark
> ---
> src/compiler/nir/nir.c| 4
> src/compiler/nir/nir_intrinsics.h | 1 +
> 2 files changed, 5 insertions(+)
>
>
On Tuesday, December 19, 2017 11:30:32 PM PST Tapani Pälli wrote:
> Signed-off-by: Tapani Pälli
> Suggested-by: Darius Spitznagel
> https://bugs.freedesktop.org/show_bug.cgi?id=104288
Bugzilla: ^
Acked-by: Kenneth Graunke
> ---
> src/util/drirc | 8
> 1 file cha
According to the RENDER_SURFACE_STATE internal documentation, the
R32G32B32_FLOAT restriction is marked "IVB" only. We choose to apply
it to Ivybridge and Baytrail, but not Haswell.
Fixes KHR-GL46.texture_size_promotion.functional on Haswell.
Changes these tests from crashing to skipping on Hasw
The hardware doesn't support this, and isl_surf_get_mcs_surf will fail.
I feel a bit bad replicating this logic, but we want to decide up front.
This fixes the following test when run with --deqp-surface-width=16384:
-
GTF-GL46.gtf30.GL3Tests.framebuffer_blit.framebuffer_blit_error_blitframebuff
On Tuesday, December 12, 2017 12:19:16 PM PST Rogovin, Kevin wrote:
> Glad that this helped. The main lead for fixing the bug I got from
> using the patch series posted earlier this week " GEM BO padding to
> find OOB buffer writes" (URL:
> https://lists.freedesktop.org/archives/mesa-dev/2017-Decem
*
>
Thank you! I'd meant to clean up the nonsense in patch 1 a while ago,
but I guess I got distracted. Good catch on the bug, too...
First is R-b, and this one gets:
Fixes: 8ecdbb61360 "i965: Pretend there are 4 subslices for compute shader
threads on Gen9+."
Bugz
On Wednesday, November 22, 2017 6:03:25 AM PST Neil Roberts wrote:
> SYSTEM_VALUE_BASE_VERTEX has changed to be the correct value for
> gl_BaseVertex, which means it will be zero when used with a
> non-indexed call. The new BASE_VERTEX_ID value can be used as before
> as an offset to calculate a va
On Wednesday, November 22, 2017 6:03:24 AM PST Neil Roberts wrote:
> The old intrinsic called base_vertex that is used to add to
> gl_VertexID is now called base_vertex_id so that base_vertex can be
> used for the value of gl_BaseVertex, which is different. As far as I
> can tell freedreno doesn’t
On Tuesday, December 5, 2017 3:23:03 PM PST Kenneth Graunke wrote:
> Reviewed-by: Kenneth Graunke
It turns out that patches 1-3 by themselves cause piles of Piglit and
CTS failures. Please make sure the series doesn't cause regressions at
each step along the way.
For reference, here
On Thursday, December 7, 2017 9:57:48 AM PST Matt Turner wrote:
[snip]
> But the entire API boils down to a comparatively small set of
> non-orthogonal state. The configuration of those nobs seems to me like
> the place things are most likely to break.
I do like Matt's idea of adding Piglit tests
On Wednesday, December 6, 2017 4:57:05 PM PST Timothy Arceri wrote:
> This fixes a crash in:
>
> KHR-GL45.enhanced_layouts.xfb_block_stride
>
> Fixes: 0822517936d4 "glsl: add helper to process xfb qualifiers during
> linking"
> Cc: Kenneth Graunke
Thanks a ton
> brw->draw.derived_draw_params_bo->size,
> 0 /* stride */,
> 0 /* step rate */);
>}
> @@ -727,7 +733,7 @@ genX(emit_vertices)(struct brw_context
t; Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103988
> Signed-off-by: Jordan Justen
> ---
> src/mesa/drivers/dri/i965/brw_link.cpp | 25 -
> 1 file changed, 16 insertions(+), 9 deletions(-)
Reviewed-by: Kenneth Graunke
signature.asc
Description: This
On Thursday, November 30, 2017 4:53:44 PM PST Rafael Antognolli wrote:
> I believe the workaround describes that the MI_LOAD_REGISTER_IMM should
> come right after the 3DSTATE_SAMPLE_PATTERN.
>
> Signed-off-by: Rafael Antognolli
> Cc: Kenneth Graunke
> ---
> src/
* aren't xyzw. This goes against the convention for other scalar
> * regs:
>
Still not clear whether this is needed for compute shaders or not.
Looks good for the other stages.
My gut feeling is that this only matters if you're doing preemption
(possibly m
ever find out a better solution,
> but it should be good enough for now.
>
> Signed-off-by: Rafael Antognolli
> Cc: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/genX_state_upload.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa
On Thursday, November 30, 2017 1:11:28 PM PST Neil Roberts wrote:
> Kenneth Graunke writes:
>
> > Neil, in case you were wondering, I suggested the above organization
> > of vertex elements because it would let us only upload 1 in the common
> > case. Looking in shader-db
On Friday, November 10, 2017 9:53:28 AM PST Antia Puentes wrote:
> Hi,
>
> the series sets gl_BaseVertex to zero for gl*DrawArrays* in i965.
[snip]
Hi Antia, Neil,
The end result of this series looks reasonable, but it looks like it's
going to break a bunch of things at each step. Either that o
> + BITFIELD64_BIT(SYSTEM_VALUE_BASE_VERTEX_ID))
> + prog_data->uses_basevertexid = true;
> +
> if (shader->info.system_values_read &
> BITFIELD64_BIT(SYSTEM_VALUE_BASE_INSTANCE))
>prog_data->uses_baseinstance = true;
>
This is fine,
ALUE(front_face, 1, 0, xx, xx, xx)
> SYSTEM_VALUE(vertex_id, 1, 0, xx, xx, xx)
> SYSTEM_VALUE(vertex_id_zero_base, 1, 0, xx, xx, xx)
> +SYSTEM_VALUE(base_vertex_id, 1, 0, xx, xx, xx)
> SYSTEM_VALUE(base_vertex, 1, 0, xx, xx, xx)
> SYSTEM_VALUE(instance_id, 1, 0, xx, xx, xx)
> SYSTEM_VAL
501 - 600 of 8758 matches
Mail list logo
