https://bugs.freedesktop.org/show_bug.cgi?id=111444
Bug 111444 depends on bug 110295, which changed state.
Bug 110295 Summary: DiRT 4 has rendering problems
https://bugs.freedesktop.org/show_bug.cgi?id=110295
What|Removed |Added
-
Mesa 19.1.7 is now available.
Caio Marcelo de Oliveira Filho (1):
glsl/nir: Avoid overflow when setting max_uniform_location
Connor Abbott (1):
radv: Call nir_propagate_invariant()
Danylo Piliaiev (1):
tgsi_to_nir: Translate TGSI_INTERPOLATE_COLOR as INTERP_MODE_NONE
Eric Eng
https://bugs.freedesktop.org/show_bug.cgi?id=111478
--- Comment #11 from Creak ---
(In reply to Rob Clark from comment #9)
> perhaps mesamatrix.net could pull data from a different sources for drivers
> that run glxinfo in CI?
I was thinking of generating features.txt by scrapping the mesa C cod
Ah, perhaps, yes. My bad.
On Tue, Sep 17, 2019 at 12:18:17AM +0200, Boris Brezillon wrote:
> On Mon, 16 Sep 2019 15:26:12 -0400
> Alyssa Rosenzweig wrote:
>
> > Well, the hash tables strongly assume you're not using NULLs for things.
> >
> > See _mesa_hash_table_set_deleted_key for how to chang
> > > +/* Start in a signaled state so that even non-submitted batches
> > > + * (those that have no draw/clear) can be waited upon.
> > > + */
> >
> > When would this happen? Presumably if a batch does nothing whatsoever,
> > it doesn't make sense to wait on it.
>
> Was
R-b
On Mon, Sep 16, 2019 at 11:37:09AM +0200, Boris Brezillon wrote:
> This will allow us to only flush batches touching a specific resource,
> which is particularly useful when the CPU needs to access a BO.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfrost/pan_job.c | 31
> > I'm wondering if batch->dependencies should be expressed as a set,
> > rather than a dynarray, such that testing whether a batch has a
> > given dependency is ideally O(1), not O(N).
> >
> > In practice I don't know if the asymptotic complexity matters, esp. for
> > small numbers of batches, a
R-b with enthusiasm :)
On Mon, Sep 16, 2019 at 11:37:10AM +0200, Boris Brezillon wrote:
> Now that we have all the pieces in place to support pipelining batches
> we can get rid of the drmSyncobjWait() at the end of
> panfrost_batch_submit().
>
> Signed-off-by: Boris Brezillon
> ---
> src/galli
R-b :D
On Mon, Sep 16, 2019 at 11:37:11AM +0200, Boris Brezillon wrote:
> Now that we have track inter-batch dependencies, the flush done in
> panfrost_set_framebuffer_state() is no longer needed. Let's get rid of
> it.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfrost/pan
R-b
On Mon, Sep 16, 2019 at 11:37:12AM +0200, Boris Brezillon wrote:
> We don't have to flush all batches when we're only interested in
> reading/writing a specific BO. Thanks to the
> panfrost_flush_batches_accessing_bo() and panfrost_bo_wait() helpers
> we can now flush only the batches touching
R-b
On Mon, Sep 16, 2019 at 11:37:13AM +0200, Boris Brezillon wrote:
> We are about to add a batch queue to keep track of submission order.
> Let's rename the existing batches hash table (which is used to get the
> batch attached to an FBO) into fbo_to_batch to avoid confusion.
>
> Signed-off-by:
Hmm, could you explain a bit why this is necessary?
I would think if there's no dependency, there's no dependency, and if
this fixes bugs, that's a dependency tracking issue that we're just
papering over.
(Also, I guess r-b on previous patch retracted temporarily since it was a setup
for
this.)
R-b, nice :)
On Mon, Sep 16, 2019 at 11:37:15AM +0200, Boris Brezillon wrote:
> All dEQP-GLES2.functional.fbo.render.texsubimage.* tests are now
> passing.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfrost/ci/expected-failures.txt | 4
> 1 file changed, 4 deletions(-)
"Can't use pipe_framebuffer_state as a hash key" Is this still relevant?
I thought we did this.
You're right that the 32-batch bitset is something we can integrate in a
v2.
I guess that's it, never mind. Good stuff regardless :)
On Tue, Sep 17, 2019 at 12:08:34AM +0200, Boris Brezillon wrote:
>
On Tue, 17 Sep 2019 08:32:35 -0400
Alyssa Rosenzweig wrote:
> Hmm, could you explain a bit why this is necessary?
>
> I would think if there's no dependency, there's no dependency, and if
> this fixes bugs, that's a dependency tracking issue that we're just
> papering over.
Indeed, there's no e
On Tue, 17 Sep 2019 08:36:56 -0400
Alyssa Rosenzweig wrote:
> "Can't use pipe_framebuffer_state as a hash key" Is this still relevant?
> I thought we did this.
I did this yes. I thought it was only a problem for the wallpaper
draw, but it's actually wrong for any kind of blit where src and
dst p
https://bugs.freedesktop.org/show_bug.cgi?id=111444
Bug 111444 depends on bug 110395, which changed state.
Bug 110395 Summary: Gen8 and lower. Shadows are flickering in SuperTuxKart
https://bugs.freedesktop.org/show_bug.cgi?id=110395
What|Removed |Added
https://bugs.freedesktop.org/show_bug.cgi?id=111444
Mark Janes changed:
What|Removed |Added
Depends on||110395
Referenced Bugs:
https://bugs.fre
https://bugs.freedesktop.org/show_bug.cgi?id=111725
Bug ID: 111725
Summary: Black screen on games "Pathfinder Kingmaker" and
"Pillars of eternity II" after saving
Product: Mesa
Version: 19.1
Hardware: x86-64 (AMD64)
19 matches
Mail list logo
