https://bugs.freedesktop.org/show_bug.cgi?id=110662
--- Comment #17 from tempel.jul...@gmail.com ---
I've added a screenshot showing the same corruption in Assassin's Creed:
Odyssey (no issues with amdvlk).
That means that likely also the titles "Syndicate" and "Origins" of that game
series are af
https://bugs.freedesktop.org/show_bug.cgi?id=110662
--- Comment #16 from tempel.jul...@gmail.com ---
Created attachment 144874
--> https://bugs.freedesktop.org/attachment.cgi?id=144874&action=edit
same corruption in Odyssey
--
You are receiving this mail because:
You are the QA Contact for the
OK. Would you mind give some link to some document what's the exact
meaning of "dependence"
in st/mesa since it's unrelated with gpu execution. Thanks.
On Fri, Jul 26, 2019 at 1:27 PM Marek Olšák wrote:
>
> The order of GPU execution doesn't matter here.
>
> M.
>
> On Fri., Jul. 26, 2019, 16:11 L
The order of GPU execution doesn't matter here.
M.
On Fri., Jul. 26, 2019, 16:11 Lepton Wu, wrote:
> I am confused, for example, according to:
>
> https://www.khronos.org/opengl/wiki/Geometry_Shader, it come after
> Vertex shader, that mean, it depends on vertex shader, right?
> So st_update_g
On Fri., Jul. 26, 2019, 15:58 Lepton Wu, wrote:
> If shader A depends on shader B, should we put st_update_shaderB in
> front of st_update_shaderA?
>
That's the current order. The order of GPU execution doesn't matter.
M.
> Now the order looks like reversed...
>
> On Fri, Jul 26, 2019 at 12
I am confused, for example, according to:
https://www.khronos.org/opengl/wiki/Geometry_Shader, it come after
Vertex shader, that mean, it depends on vertex shader, right?
So st_update_gp should be after st_update_vp, but now it is in the
front of st_update_vp.
On Fri, Jul 26, 2019 at 1:07 PM Mar
If shader A depends on shader B, should we put st_update_shaderB in
front of st_update_shaderA?
Now the order looks like reversed...
On Fri, Jul 26, 2019 at 12:34 PM Marek Olšák wrote:
>
> The order shouldn't matter, but there can be a reason behind it, e.g. if a
> shader depends on the updat
The order shouldn't matter, but there can be a reason behind it, e.g. if a
shader depends on the update of the following shader.
Marek
On Wed, Jul 24, 2019 at 7:19 PM Lepton Wu wrote:
> In src/mesa/state_tracker/st_atom_list.h,
>
> Now it's this order:
>
> ST_STATE(ST_NEW_FS_STATE, st_update_fp
Reviewed-by: Marek Olšák
Marek
On Thu, Jul 25, 2019 at 11:30 PM Ilia Mirkin wrote:
> This caused nouveau's function handling logic to think that the MAIN
> function was due to receive external parameters, and cascaded some
> failures after that. Instead avoid having the undefined components in
On Fri, 2019-07-26 at 10:41 -0400, Ilia Mirkin wrote:
> On Wed, Jul 24, 2019 at 9:34 AM Juan A. Suarez Romero
> wrote:
> > On Wed, 2019-07-24 at 14:27 +0200, Karol Herbst wrote:
> > > it's only fixing a crash in a build with asserts enabled, but if
> > > somebody wants to apply those to stable, th
On Wed, Jul 24, 2019 at 9:34 AM Juan A. Suarez Romero
wrote:
>
> On Wed, 2019-07-24 at 14:27 +0200, Karol Herbst wrote:
> > it's only fixing a crash in a build with asserts enabled, but if
> > somebody wants to apply those to stable, then go ahead.
> >
>
> OK; in that case I will keep it out.
Loo
https://bugs.freedesktop.org/show_bug.cgi?id=99553
--- Comment #19 from kaitlynkristy ---
Here is a problem.
I updated LLVM-trunk and installed.
Than run this commands:
git clone http://llvm.org/git/libclc.git
cd libclc
./configure.py
make
More info:
https://www.fieldengineer.com/blogs/new-jers
On Fri, Jul 26, 2019 at 2:59 PM Ilia Mirkin wrote:
>
> Thanks! I had to make a small update to the asserts:
>
> assert(nvc0->constbuf[5][0].user || !nvc0->constbuf[5][0].u.buf);
>
> u.buf is not valid to check when .user is set. (in fact it aliases
> with the "data" pointer)
>
> Let me know if you
Thanks! I had to make a small update to the asserts:
assert(nvc0->constbuf[5][0].user || !nvc0->constbuf[5][0].u.buf);
u.buf is not valid to check when .user is set. (in fact it aliases
with the "data" pointer)
Let me know if you want me to resend.
On Fri, Jul 26, 2019 at 5:51 AM Karol Herbst
I think this was there for generic support for functions actually and
that for OpenCL + TGSI the idea was to not inline everything by
default, so return values were handled there as well.
The proper way to handle is, to declare kernel inputs as real inputs,
because kernel inputs are fundamentally
Reviewed-by: Karol Herbst
On Fri, Jul 26, 2019 at 7:03 AM Ilia Mirkin wrote:
>
> This can happen if it's e.g. a uniform or a function argument.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111217
> Signed-off-by: Ilia Mirkin
> Cc: mesa-sta...@lists.freedesktop.org
> ---
> src/gal
Reviewed-by: Karol Herbst
On Fri, Jul 26, 2019 at 5:31 AM Ilia Mirkin wrote:
>
> The meson conversion chose to change the meaning of DEBUG to "used for
> debugging" to be "used for expensive things for debugging", primarily
> for nir_validate. Flip things over so that we get nice things with
> o
Reviewed-by: Karol Herbst
On Fri, Jul 26, 2019 at 5:31 AM Ilia Mirkin wrote:
>
> Previously the code only handled it for positions 1 and up (as would be
> for UBO's in GL). It's not a lot of trouble to handle this, and vl or
> vdpau want this.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.
Reviewed-by: Karol Herbst
On Fri, Jul 26, 2019 at 5:31 AM Ilia Mirkin wrote:
>
> Apparently vl (or vdpau) wants to pass that in now. Handle it.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111213
> Signed-off-by: Ilia Mirkin
> Cc: mesa-sta...@lists.freedesktop.org
> ---
> src/gal
https://bugs.freedesktop.org/show_bug.cgi?id=26
--- Comment #7 from Jordan Justen ---
(In reply to Dylan Baker from comment #5)
> Are you doing a cross compile?
I am not cross compiling.
I do set PKG_CONFIG_PATH, but it includes the system path
where the wayland-scanner.pc is at. Yet, from
https://bugs.freedesktop.org/show_bug.cgi?id=26
--- Comment #6 from Jordan Justen ---
(In reply to Emil Velikov from comment #4)
> Yet I won't object if you want to revert my patch.
I don't want to revert this patch. I'm hoping that either you
or Dylan can reproduce it with 0.51, and figure
On Wed, 2019-06-19 at 17:04 -0400, boyuan.zh...@amd.com wrote:
> From: Boyuan Zhang
>
> Set cu_qp_delta_enable_flag on when rate control is enabled, and set it
> off when rate control is disabled (e.g. constant qp).
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110673
> Cc: mesa-sta
22 matches
Mail list logo
