Divergence is generally when multiple parallel "lanes" go in different
directions -- a jump that some lanes take and others don't, which
requires the GPU to execute some lanes first, and then the rest,
separately.
IMO better names might be is_scalar_swizzle or something.
On Mon, May 6, 2019 at 11
On Wed, May 1, 2019 at 12:30 AM Dave Airlie wrote:
>
> From: Dave Airlie
>
> If no view is bound we still should reset the override to 0
> and array mode.
>
> This should fix misrendering in firefox WebRender since
> the pbo sampler was removed.
>
> Fixes: 1250383e36 (st/mesa: remove sampler asso
On Tue, Apr 30, 2019 at 10:42 AM Ilia Mirkin wrote:
>
> On Tue, Apr 30, 2019 at 2:48 AM Dave Airlie wrote:
> >
> > On Tue, 30 Apr 2019 at 08:47, Dave Airlie wrote:
> > >
> > > On Tue, 30 Apr 2019 at 08:42, Ilia Mirkin wrote:
> > > >
> > >
On Tue, Apr 30, 2019 at 2:48 AM Dave Airlie wrote:
>
> On Tue, 30 Apr 2019 at 08:47, Dave Airlie wrote:
> >
> > On Tue, 30 Apr 2019 at 08:42, Ilia Mirkin wrote:
> > >
> > > Thing is, I think that would not be enough - with the "recent" (like
šák wrote:
>
> Reverting the st/mesa commit would be fine.
>
> Marek
>
> On Mon, Apr 29, 2019 at 3:20 PM Ilia Mirkin wrote:
>>
>> On Mon, Apr 29, 2019 at 3:06 PM Viktor Jaegerskuepper
>> wrote:
>> >
>> > Hi Ilia,
>> >
>> > Il
On Mon, Apr 29, 2019 at 3:06 PM Viktor Jaegerskuepper
wrote:
>
> Hi Ilia,
>
> Ilia Mirkin:
> > If you can reproduce the issue
> > at will, could I recommend you try undoing this hunk:
> >
> > @@ -1192,7 +1192,6 @@ try_pbo_upload_common(struct gl_c
roblems on Fermi. I didn't work out the reasons, but
> the solution was simple -- just put the samplers back in.
>
> Since then, regular texturing paths appear to have lost their associated
> samplers which required a fuller investigation and fix in nouveau. Now
> that this is done
On Thu, Apr 25, 2019 at 6:37 PM Alyssa Rosenzweig wrote:
> Various combinations of these instructions are found on many
> architectures. They appear directly as-is on Midgard; some of them
> should be implementable on Intel Gen8+ via the source modifiers; I was
> told over IRC that AMD/Nouveau mig
Hi all,
I've put together a GLSL extension proposal at:
https://people.freedesktop.org/~imirkin/MESA_debug_operations.spec
The situation this is trying to alleviate is the fact that it's an
_enormous_ pain to actually execute shaders and collect results on any
particular hardware without a surro
llvmpipe takes a number of shortcuts in the interest of speed which
cause inaccurate texturing. Try running with
GALLIVM_DEBUG=no_rho_approx,no_brilinear,no_quad_lod
and see if the issue still occurs.
Cheers,
-ilia
On Thu, Apr 11, 2019 at 8:30 AM Dominik Drees wrote:
>
> Hello, everyone!
On Wed, Apr 10, 2019 at 7:31 AM Andres Gomez wrote:
> On Wed, 2019-04-10 at 10:40 +1000, Timothy Arceri wrote:
> > On 13/2/19 8:57 am, Andres Gomez wrote:
> > > @@ -1764,6 +1765,8 @@ struct gl_transform_feedback_buffer
> > >
> > > uint32_t NumVaryings;
> > >
> > > + BITSET_WORD *UsedCompone
s (within the gpu and within the
> driver/host communication) ?
>
> El mié., 10 abr. 2019 a las 0:56, Ilia Mirkin ()
> escribió:
>>
>> Hi Fernando,
>>
>> Perhaps you can elaborate? The question doesn't really make sense to me.
>>
>> What regi
On Tue, Apr 2, 2019 at 2:22 PM Zhu, James wrote:
>
> Add memory barrier sync and unbind resource after launch will enhance
> the robustness.
I can't tell from the comment -- is this working around driver bugs,
or is the state tracker using the API incorrectly and this fixes the
usage. If the latt
On Wed, Apr 3, 2019 at 9:36 AM Marek Olšák wrote:
>
> On Wed, Apr 3, 2019 at 9:06 AM Ilia Mirkin wrote:
>>
>> On Wed, Apr 3, 2019 at 8:38 AM Marek Olšák wrote:
>> >
>> > On Tue, Apr 2, 2019 at 2:14 PM Eric Anholt wrote:
>> >>
>> >&g
On Wed, Apr 3, 2019 at 8:38 AM Marek Olšák wrote:
>
> On Tue, Apr 2, 2019 at 2:14 PM Eric Anholt wrote:
>>
>> Ilia Mirkin writes:
>>
>> > Shouldn't this sort of decision be left up to the driver? If the
>> > driver would like to use CS for blits,
Shouldn't this sort of decision be left up to the driver? If the
driver would like to use CS for blits, fine, but why not let it blit
in the most optimal way possible and force it to use a compute shader?
On Tue, Apr 2, 2019 at 1:44 PM Jiang, Sonny wrote:
>
> Signed-off-by: Sonny Jiang
> ---
>
Just an observation...
f2b(0x8000) == false
i2b(0x8000) == true
I haven't read surrounding code, but if the handling of f2b and i2b is
entirely identical, you'll run into trouble.
Cheers,
-ilia
On Tue, Mar 26, 2019 at 12:59 AM Alyssa Rosenzweig wrote:
>
> Fixes
> dEQP-GLES2.function
Reviewed-by: Ilia Mirkin
On Thu, Mar 21, 2019 at 9:55 AM Rob Clark wrote:
>
> Adds a new cap to allow drivers to expose higher shading language
> versions in GLES contexts, to avoid having to report an artificially
> low version for the benefit of GL contexts.
>
> The motiv
Reviewed-by: Ilia Mirkin
Thanks for bearing with my nits.
On Thu, Mar 21, 2019 at 2:43 PM Rob Clark wrote:
>
> For GLES2+ contexts, enable EXT_gpu_shader5 if the driver exposes a
> sufficiently high ESSL feature level, even if the GLSL feature level
> isn't high enough.
>
&
On Thu, Mar 21, 2019 at 1:45 PM Rob Clark wrote:
>
> For GLES2+ contexts, enable EXT_gpu_shader5 if the driver exposes a
> sufficiently high ESSL feature level, even if the GLSL feature level
> isn't high enough.
>
> This allows drivers to support EXT_gpu_shader5 in GLES contexts before
> they sup
On Thu, Mar 21, 2019 at 10:18 AM Rob Clark wrote:
>
> On Thu, Mar 21, 2019 at 10:09 AM Ilia Mirkin wrote:
> >
> > On Thu, Mar 21, 2019 at 9:55 AM Rob Clark wrote:
> > >
> > > For GLES2+ contexts, enable EXT_gpu_shader5 if the driver exposes a
> > >
On Thu, Mar 21, 2019 at 9:55 AM Rob Clark wrote:
>
> For GLES2+ contexts, enable EXT_gpu_shader5 if the driver exposes a
> sufficiently high ESSL feature level, even if the GLSL feature level
> isn't high enough.
>
> This allows drivers to support EXT_gpu_shader5 in GLES contexts before
> they sup
On Wed, Mar 6, 2019 at 3:32 AM Kenneth Graunke wrote:
>
> The glMemoryBarrier() function makes shader memory stores ordered with
> respect to things specified by the given bits. Until now, st/mesa has
> ignored GL_TEXTURE_UPDATE_BARRIER_BIT and GL_BUFFER_UPDATE_BARRIER_BIT,
> saying that drivers
On Fri, Mar 15, 2019 at 11:52 AM Connor Abbott wrote:
>
> On Fri, Mar 15, 2019 at 3:46 PM Ilia Mirkin wrote:
> >
> > On Fri, Mar 15, 2019 at 10:29 AM Alyssa Rosenzweig
> > wrote:
> > >
> > > > This is needed if you can only handle point sprites on
On Fri, Mar 15, 2019 at 10:29 AM Alyssa Rosenzweig wrote:
>
> > This is needed if you can only handle point sprites on certain
> > varyings but not others. This is the case for nv30- and nvc0-based
> > GPUs, which is why the cap was introduced.
> >
> > If your GPU does not have such restrictions,
On Fri, Mar 15, 2019 at 8:21 AM Axel Davy wrote:
> This is compatible with what I said. Nouveau determines the minimum
> number of samplers actually needed
> by the current shader, and internally unbinds those above (and rebinds
> if needed by new shader).
The things nouveau does today aren't nec
This is needed if you can only handle point sprites on certain
varyings but not others. This is the case for nv30- and nvc0-based
GPUs, which is why the cap was introduced.
If your GPU does not have such restrictions, you can safely remove the cap.
-ilia
On Fri, Mar 15, 2019 at 12:25 AM Alyssa
I believe the distinction here is between initializing all the fields
and using them individually (thus leaving the padding uninitialized),
vs using the fields to create a structure to hash as a sequence of
bytes. For the latter, you really need all the memory initialized, not
just the "valid" part
On Mon, Mar 11, 2019 at 8:18 PM Karol Herbst wrote:
>
> On Tue, Mar 12, 2019 at 1:09 AM Ilia Mirkin wrote:
> >
> > On Mon, Mar 11, 2019 at 8:05 PM Karol Herbst wrote:
> > >
> > > v9: convert to C++ style comments
> > > Signed-off-by: Karol Herbst
On Mon, Mar 11, 2019 at 8:05 PM Karol Herbst wrote:
>
> v9: convert to C++ style comments
> Signed-off-by: Karol Herbst
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/nouveau/codeg
On Sun, Feb 24, 2019 at 1:36 AM Alyssa Rosenzweig wrote:
>
> Signed-off-by: Alyssa Rosenzweig
> ---
> src/gallium/drivers/panfrost/include/panfrost-job.h | 2 ++
> src/gallium/drivers/panfrost/pan_pretty_print.c | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/src/gallium/drivers/
On Thu, Feb 21, 2019 at 11:09 AM Marek Olšák wrote:
>
> On Thu, Feb 21, 2019, 12:08 AM Ilia Mirkin wrote:
>>
>> I don't think that's right... this is used in e.g.
>>
>>case TGSI_OPCODE_RESQ:
>> if (tgsi_is_bindless_image_file(ful
I don't think that's right... this is used in e.g.
case TGSI_OPCODE_RESQ:
if (tgsi_is_bindless_image_file(fullinst->Src[0].Register.File))
info->uses_bindless_images = true;
break;
And if you call RESQ with a src0 that is not IMAGE or BUFFER, then
that's a bindless referen
On Fri, Feb 15, 2019 at 3:55 AM Timothy Arceri wrote:
>
> On 15/2/19 4:12 pm, Jason Ekstrand wrote:
> > I think the primary issue we had with dead ifs before is that we were
> > running dce and dead_cf but maybe not peephole_select because it didn't
> > seem applicable. In principle, I think I li
On Thu, Feb 14, 2019 at 11:53 AM Erik Faye-Lund
wrote:
>
> On Thu, 2019-02-14 at 16:25 +0100, Gert Wollny wrote:
> > > > > On Wed, Feb 13, 2019 at 11:09 AM Elie Tournier <
> > > > > tournier.e...@gmail.com> wrote:
> > [...]
> > > > > > A solution would be to inline the
> > > > > > function in GLS
Unfortunately swr was missed in the original commit. The number of
varyings should generally match up to what's reported as the shader
caps for fragment inputs.
Fixes: 6010d7b8e8be (gallium: add PIPE_CAP_MAX_VARYINGS)
Signed-off-by: Ilia Mirkin
Cc: 19.0
---
src/gallium/driver
On Wed, Feb 13, 2019 at 9:52 PM Alyssa Rosenzweig wrote:
>
> Setting this is required for desktop-style occlusion queries.
>
> Signed-off-by: Alyssa Rosenzweig
> ---
> src/gallium/drivers/panfrost/include/panfrost-job.h | 10 ++
> src/gallium/drivers/panfrost/pan_context.c | 2
On Wed, Feb 13, 2019 at 1:29 PM Elie Tournier wrote:
>
>
>
> On Wednesday, 13 February 2019, Ilia Mirkin wrote:
>>
>> On Wed, Feb 13, 2019 at 12:47 PM Elie Tournier
>> wrote:
>> >
>> > On Fri, Jan 25, 2019 at 11:52:56AM -0800, Stéphane Marches
On Wed, Feb 13, 2019 at 12:47 PM Elie Tournier wrote:
>
> On Fri, Jan 25, 2019 at 11:52:56AM -0800, Stéphane Marchesin wrote:
> > On Fri, Jan 25, 2019 at 2:25 AM Gert Wollny wrote:
> > >
> > > Am Donnerstag, den 24.01.2019, 22:25 -0800 schrieb Stéphane Marchesin:
> > > >
> > > > Yes, it's for run
On Tue, Feb 12, 2019 at 11:13 PM Jason Ekstrand wrote:
>
> On February 12, 2019 21:40:49 Ilia Mirkin wrote:
>
> > If the driver supports PIPE_BIND_BLENABLE on RGBA32F, flip
> > EXT_float_blend on (which will affect ES3 contexts).
> >
> > Signed-off-by:
From the table in isl_format.c, it appears that all generations
support blending on 32-bit float surfaces.
Signed-off-by: Ilia Mirkin
---
src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
b/src/mesa
If EXT_float_blend is not supported, error out on blending of FP32
attachments in an ES2 context.
Signed-off-by: Ilia Mirkin
---
src/mesa/main/draw_validate.c| 19 +++
src/mesa/main/extensions_table.h | 2 +-
src/mesa/main/fbobject.c | 4
src/mesa/main
If the driver supports PIPE_BIND_BLENABLE on RGBA32F, flip
EXT_float_blend on (which will affect ES3 contexts).
Signed-off-by: Ilia Mirkin
---
src/mesa/state_tracker/st_extensions.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src
For some reason we don't use view volume clipping by default, and use
scissors instead. These scissors were set to an 8k max fb size, while
the driver advertises 16k-sized framebuffers.
Signed-off-by: Ilia Mirkin
Cc:
---
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 4 ++--
1 file ch
On Fri, Feb 8, 2019 at 8:27 PM Alyssa Rosenzweig wrote:
>
> The previous code for handling viewport changes and scissors was ad hoc
> and subject to edge cases. This patch unifies and streamlines these
> routines, improving code quality and partially fixing the scissor test.
>
> Signed-off-by: Aly
On Fri, Feb 8, 2019 at 8:24 PM Alyssa Rosenzweig wrote:
>
> Midgard has native support for QUADS and POLYGONS; Bifrost seemingly
> does not. Thus, Midgard generally skips prim_convert whereas Bifrost
> needs the pass; this patch allows the setting of allowed primitives to
> occur on a per-context
On Thu, Feb 7, 2019 at 12:17 PM Eleni Maria Stea wrote:
>
> On Thu, 7 Feb 2019 11:18:59 -0500
> Ilia Mirkin wrote:
>
> > On Thu, Feb 7, 2019 at 2:49 AM Eleni Maria Stea
> > wrote:
> > >
> > > On Wed, 6 Feb 2019 12:12:27 -0800
> > > Nanley
On Thu, Feb 7, 2019 at 2:49 AM Eleni Maria Stea wrote:
>
> On Wed, 6 Feb 2019 12:12:27 -0800
> Nanley Chery wrote:
>
> > > + * For now, we can't enable OES_texture_view on Gen 7
> > > because of
> > > + * some piglit failures coming from
> > > + * piglit/tests/spec/arb_texture_v
From: Karol Herbst
If the driver does not support rendering to these formats but does
support texturing, we can end up in incompatibilities between textures
and renderbuffers that are then copied to.
Fixes KHR-GL45.copy_image.functional on nvc0
Reviewed-by: Ilia Mirkin
Cc: 19.0
---
I think
.
Fixes KHR-GL45.limits.max_fragment_input_components
Signed-off-by: Karol Herbst
[imirkin: rebased, improved docs/commit message]
Signed-off-by: Ilia Mirkin
Cc: 19.0
---
I'd really like to get this into 19.0, since it's such a small change
logically. However it does impact every dri
Actually Karol had already done this in a way that I think is better
-- by introducing a special PIPE_CAP_MAX_VARYINGS. This patch is
withdrawn, I'm going to go with his approach (tonight).
On Tue, Feb 5, 2019 at 1:06 AM Ilia Mirkin wrote:
>
> NVIDIA hardware is weird. The fragment sh
rates INPUT_COMPONENTS from INPUTS, and links up
INPUT_COMPONENTS to the proper limit. For all drivers other than nvc0,
this is set to 4 * INPUTS.
Signed-off-by: Ilia Mirkin
Cc: 19.0
---
This is a conformance issue for nouveau, so I'd like to get it into the
next release. Should have no effect o
Fixes KHR-GL45.conditional_render_inverted.functional
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nv50/nv50_query.c | 10 --
.../drivers/nouveau/nv50/nv50_query_hw.c| 8 +---
.../drivers/nouveau/nv50/nv50_query_hw.h| 6 +-
src/gallium/drivers/nouveau/nvc0/nvc0
t;
> El 22/11/18 a las 0:28, Chema Casanova escribió:
> >
> >
> > On 21/11/18 20:04, Ilia Mirkin wrote:
> >> On Wed, Nov 21, 2018 at 1:45 PM Jose Maria Casanova Crespo
> >> wrote:
> >>>
> >>> Recent change on OpenGL CTS ("Use non-array
On Mon, Feb 4, 2019 at 7:38 PM Jason Ekstrand wrote:
>
> On Mon, Feb 4, 2019 at 6:25 PM Alyssa Rosenzweig wrote:
>>
>> > Actually, I just gave you (Alyssa) push access... Also, as you'll (as
>> > far as I understand) basically be owning the panfrost bits in mesa,
>> > you should be able to commit
On Mon, Feb 4, 2019 at 7:43 AM Andres Gomez wrote:
>
> On Fri, 2019-02-01 at 13:17 -0500, Ilia Mirkin wrote:
> > On Fri, Feb 1, 2019 at 1:08 PM Andres Gomez wrote:
> > > Current implementation uses a complicated calculation which relies in
> > > an implicit convers
optionally treat every 2d case as if it could be a
slice of a 3d texture.
Signed-off-by: Ilia Mirkin
---
.../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 45 +++
src/gallium/drivers/nouveau/nvc0/nvc0_tex.c | 23 --
2 files changed, 34 insertions(+), 34 deletions(-)
diff -
rsists for non-atomic buffers, which will have to be
fixed separately.
Fixes the failing dEQP-GLES31.functional.atomic_counter.* tests.
Signed-off-by: Ilia Mirkin
---
.../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff -
y unlikely to ever be used with
indirect draws, read the indirect buffer on the CPU and issue draws
directly.
Fixes the failing dEQP-GLES31.functional.draw_indirect.random.* tests.
Signed-off-by: Ilia Mirkin
---
.../drivers/nouveau/nvc0/nvc0_context.h | 1 +
src/gallium/drivers/no
wide argument.
An additional benefit of this approach is that we don't have needless
stores of 0 into registers.
Fixes MISALIGNED_REG errors in Hitman when run with bindless textures
enabled on a GK208.
Fixes: 9145873b152 ("nvc0/ir: use levelZero flag when the lod is set to 0")
Signed
On Fri, Feb 1, 2019 at 1:08 PM Andres Gomez wrote:
>
> If there is no Static Use of an input variable, the linker shouldn't
> fail whenever there is no defined matching output variable in the
> previous stage.
>
> From page 47 (page 51 of the PDF) of the GLSL 4.60 v.5 spec:
>
> " Only the input
This causes a O(N^2) behavior in the number of feedback'd variables,
which I suspect is undesirable. Elsewhere we use arrays and/or maps --
since the size of the xfb offset has a max value, an array-based
solution may work well.
On Fri, Feb 1, 2019 at 1:08 PM Andres Gomez wrote:
>
> From page 76
On Fri, Feb 1, 2019 at 1:08 PM Andres Gomez wrote:
>
> Current implementation uses a complicated calculation which relies in
> an implicit conversion to check the integral part of 2 division
> results.
>
> However, the calculation actually checks that the xfb_offset is
> smaller or a multiplier of
Reviewed-by: Ilia Mirkin
Note - not sure that initializing pad is necessary. And there's a
handful of fields missing (like the draw id comes to mind). But ...
it's not important. Sorry again for the screwup!
On Tue, Jan 29, 2019 at 4:17 PM Brian Paul wrote:
>
> LGTM. Reviewe
Would it be wise to just initialize everything explicitly? For example
this is what _mesa_draw_arrays does:
memset(&prim, 0, sizeof(prim));
prim.begin = 1;
prim.end = 1;
prim.mode = mode;
prim.num_instances = numInstances;
prim.base_instance = baseInstance;
prim.draw_id = draw
Reviewed-by: Ilia Mirkin
On Mon, Jan 28, 2019 at 5:47 PM Karol Herbst wrote:
>
> gives me an performance boost of 0.2% in pixmark_piano on my gk106, gm204 and
> gp107.
>
> reduces the amount of generated convert instructions by roughly 30% in
> shader-db.
>
> v2: on
On Mon, Jan 28, 2019 at 4:21 PM Karol Herbst wrote:
>
> gives me an performance boost of 0.2% in pixmark_piano on my gk106, gm204 and
> gp107.
>
> reduces the amount of generated convert instructions by roughly 30% in
> shader-db.
>
> v2: only for 32 bit operations
> move some common code out
A few thoughts. Given past experience, I don't really expect these to
have any serious impact on the direction taken, but I also don't want
to just sit brooding in silence. Please note that full time/paid
contributors probably have a different view of things than volunteer
contributors. There's not
The text segment is shared among multiple contexts, while each one has
its own bufctx. So when reallocating the text segment, some contexts may
end up with stale values in their bufctx's. Instead limit the exposure
to the bufctx to within a single draw.
Signed-off-by: Ilia Mirkin
--
On Fri, Jan 25, 2019 at 10:58 AM Ilia Mirkin wrote:
>
> IMAD_S24 isn't src0 * src1 + src2 though. I think this could be called
> imad24, which I suspect exits on many GPUs (nv50-era NVIDIA definitely
> had this, and I think maxwell+ has a variant of this implemented by
> XMA
IMAD_S24 isn't src0 * src1 + src2 though. I think this could be called
imad24, which I suspect exits on many GPUs (nv50-era NVIDIA definitely
had this, and I think maxwell+ has a variant of this implemented by
XMAD):
(src0 * src1) & 0xff + src2
Cheers,
-ilia
On Fri, Jan 25, 2019 at 10:49
The text segment is shared among multiple contexts, while each one has
its own bufctx. So when reallocating the text segment, some contexts may
end up with stale values in their bufctx's. Instead limit the exposure
to the bufctx to within a single draw.
Signed-off-by: Ilia Mirkin
---
was
in effect, and then render to a different texture. This seems legal
under the "no feedback loops" rule.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nv50/nv50_state.c | 2 +-
src/gallium/drivers/nouveau/nvc0/nvc0_state.c | 4 +++-
2 files changed, 4 insertions(+), 2
While you're at it, also copy precision. I think that's the only other
relevant bit. With that,
Reviewed-by: Ilia Mirkin
On Sat, Jan 19, 2019 at 6:58 PM Karol Herbst wrote:
>
> fixes a couple of deqp tests (on nvc0 and potential other driver
Reviewed-by: Ilia Mirkin
On Sat, Jan 19, 2019 at 6:34 PM Rhys Kidd wrote:
>
> Signed-off-by: Rhys Kidd
> ---
> src/gallium/drivers/nouveau/nv50/nv50_screen.c | 2 ++
> src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 ++
> 2 files changed, 4 insertions(+)
>
>
I believe it should work in principle [at least the tegra drm +
nouveau bit, perhaps not the android things], however it's not
well-tested. I have a Jetson TK1, but it dies fairly instantaneously
once any network goes through the NIC, which is a bad situation for a
netboot setup.
If you're interes
Still some bits missing (I think from 4/5):
NVC0LoweringPass::handleSurfaceOpGM107(TexInstruction *su)
{
processSurfaceCoordsGM107(su);
if (su->op == OP_SULDP) {
convertSurfaceFormat(su);
insertOOBSurfaceOpResult(su);
}
and convertSurfaceFormat will unconditionally flip SULD
On Wed, Jan 16, 2019 at 6:20 PM Rhys Perry wrote:
>
> v3: rebase
>
> Signed-off-by: Rhys Perry
> Reviewed-by: Marek Olšák (v2)
> ---
> src/compiler/glsl/ast_to_hir.cpp | 5 +
> src/compiler/glsl/glsl_parser_extras.cpp | 1 +
> src/compiler/glsl/glsl_parser_extras.h | 7 +++
>
Currently we were only returning it for BGRA8. But it makes sense to
return it for all the BGR[AX] variants. This was discovered when
figuring out why wlroots was sending a RGBX instead of BGRX image when
screenshotting.
Signed-off-by: Ilia Mirkin
---
Not sure that this can really matter for
On Sat, Jan 12, 2019 at 9:40 AM Gert Wollny wrote:
> I will not push it with
> the strong NAK you gave, Ilia. To me consensus means that all who
> contribute significantly to the project (like you certainly do) agree
> or abstain, but don't object.
A single actor should not prevent a group from a
On Fri, Jan 11, 2019 at 5:38 PM Matt Turner wrote:
>
> On Fri, Jan 11, 2019 at 2:28 PM Ilia Mirkin wrote:
> >
> > On Fri, Jan 11, 2019 at 5:12 PM Matt Turner wrote:
> > >
> > > From: Gert Wollny
> > >
> > > Since Meson will eventually be t
On Fri, Jan 11, 2019 at 5:12 PM Matt Turner wrote:
>
> From: Gert Wollny
>
> Since Meson will eventually be the only build system deprecate autotools
> now. It can still be used by invoking configure with the flag
> --enable-autotools
>
> NAKed-by: Ilia Mirkin
[no
On Tue, Jan 8, 2019 at 7:26 PM Marek Olšák wrote:
>
> On Tue, Jan 8, 2019 at 7:18 PM Ilia Mirkin wrote:
>>
>> On Tue, Jan 8, 2019 at 6:21 PM Marek Olšák wrote:
>> >
>> > On Tue, Jan 8, 2019 at 5:25 PM Ilia Mirkin wrote:
>> >>
>> >>
On Tue, Jan 8, 2019 at 6:21 PM Marek Olšák wrote:
>
> On Tue, Jan 8, 2019 at 5:25 PM Ilia Mirkin wrote:
>>
>> Why does this need to be in p_state? And who is responsible for
>> setting it (and how will it be set)?
>
>
> Oh right, there is a way to get it out of p
Why does this need to be in p_state? And who is responsible for
setting it (and how will it be set)?
On Tue, Jan 8, 2019 at 2:47 PM Jiang, Sonny wrote:
>
> and add radeonsi support. This will be used by radeonsi internally.
>
> Signed-off-by: Sonny Jiang
> ---
> src/gallium/drivers/radeonsi/si_
Reviewed-by: Ilia Mirkin
Thanks!
On Tue, Dec 18, 2018 at 5:41 PM Dylan Baker wrote:
>
> This has never functioned and probably wont ever function, due to the
> way gallium media state trackers are architected and the tegra video
> decoder is architected.
>
> Cc: Thier
It looks like as of Chromium 71, nouveau is completely blacklisted.
I don't really see a way back from this, since they don't cite any
easily reproducible issues, except that some people had some issues
with indeterminate hardware and indeterminate versions of mesa.
In the bug that triggered this
On Fri, Jan 4, 2019 at 5:04 PM Ilia Mirkin wrote:
>
> On Fri, Jan 4, 2019 at 4:56 PM Kevin Strasser
> wrote:
> > diff --git a/src/mesa/drivers/dri/common/utils.c
> > b/src/mesa/drivers/dri/common/utils.c
> > index b52c59f..1cf9362 100644
> > --- a/src/mesa/dri
On Fri, Jan 4, 2019 at 4:56 PM Kevin Strasser wrote:
> diff --git a/src/mesa/drivers/dri/common/utils.c
> b/src/mesa/drivers/dri/common/utils.c
> index b52c59f..1cf9362 100644
> --- a/src/mesa/drivers/dri/common/utils.c
> +++ b/src/mesa/drivers/dri/common/utils.c
> @@ -200,6 +200,10 @@ driCreateC
llabora.com> wrote:
>> > > On Wed, 2019-01-02 at 10:16 -0600, Jason Ekstrand wrote:
>> > > > On Wed, Jan 2, 2019 at 9:43 AM Ilia Mirkin
>> > > > wrote:
>> > > > > Have a look at the first 4 patches in the series from Jonathan
>> &g
On Wed, Jan 2, 2019 at 11:17 AM Jason Ekstrand wrote:
>
> On Wed, Jan 2, 2019 at 9:43 AM Ilia Mirkin wrote:
>>
>> Have a look at the first 4 patches in the series from Jonathan Marek
>> to address some of these issues:
>>
>> https://patchwork.freedesktop.org/
Have a look at the first 4 patches in the series from Jonathan Marek
to address some of these issues:
https://patchwork.freedesktop.org/series/54295/
Not sure exactly what state that work is in, but I've added Jonathan
to CC, perhaps he can provide an update.
Cheers,
-ilia
On Wed, Jan 2, 201
On Sat, Dec 29, 2018 at 6:17 AM Mathias Fröhlich
wrote:
> In Emils patches building on top, _eglGetDRMDeviceRenderNode is only called
> from
> code paths guarded with HAVE_LIBDRM.
OK, so we could also guard the function's existence on HAVE_LIBDRM as
well. I think that's the most logical way forw
27;d rather stick the entire function under a HAVE_LIBDRM guard
instead of having it return NULL unexpectedly. But I'd definitely like
to hear from Emil in case I'm missing something.
On Thu, Dec 27, 2018 at 3:59 PM Ilia Mirkin wrote:
>
> I don't see this function used anywhere...
I don't see this function used anywhere... it's not exported either.
It was added in dbb4457d9858fa977246aa5e9cabe83455022dfe by Emil as
part of EGL_EXT_device_drm, but appears unused in that commit as well.
Emil - can this function just be removed perhaps?
-ilia
On Thu, Dec 27, 2018 at 3:47
appen strictly after a validation is
run.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102349
Signed-off-by: Ilia Mirkin
---
Fairly sure this should be EXTREMELY difficult to trigger in practice,
but this is the only use PUSH_RESET not in a validation path. Fix it.
src/gallium/drivers/no
still pointing at some old context. Then we wouldn't run the
switch logic, which in turn led to a NULL bufctx being dereferenced.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102349
Signed-off-by: Ilia Mirkin
---
This is the underlying issue of the referenced bug
src/gallium/drivers/no
Make sure that the next line starts with spaces so that bullets are
maintained throughout, add `` around a few more special tokens, and fix
SAMPLE_COUNT_TEXTURE -> SAMPLE_COUNT.
Signed-off-by: Ilia Mirkin
---
Hardly exhaustive or complete, but a handful of things I noticed.
src/gallium/d
On Wed, Dec 19, 2018 at 10:12 AM Brian Paul wrote:
>
> On 12/19/2018 06:47 AM, Ilia Mirkin wrote:
> > On Wed, Dec 19, 2018 at 8:38 AM Brian Paul wrote:
> >>
> >> On 12/18/2018 08:50 PM, Ilia Mirkin wrote:
> >>> Not sure if this ever worked, but the c
On Wed, Dec 19, 2018 at 1:30 PM Dylan Baker wrote:
>
> Quoting Nicolai Hähnle (2018-12-18 09:37:43)
> > On 17.12.18 23:46, Dylan Baker wrote:
> > > Quoting Marek Olšák (2018-12-17 12:25:29)
> > >> On Mon, Dec 17, 2018 at 1:18 PM Eric Anholt wrote:
> > >>
> > >> Eero Tamminen writes:
> > >>
101 - 200 of 5930 matches
Mail list logo
