https://bugs.freedesktop.org/show_bug.cgi?id=110253
Bug ID: 110253
Summary: glBlitFramebuffer fails on MSAA fbo source.
Product: Mesa
Version: 19.0
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Seve
https://bugs.freedesktop.org/show_bug.cgi?id=110252
Bug ID: 110252
Summary: swr software rasterizer fall back to OpenGL 2.1
Product: Mesa
Version: 19.0
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Do nir_lower_viewport_transform when driver set
PIPE_CAP_NIR_VS_LOWER_VIEWPORT_TRANSFORM in vertex
shader.
Signed-off-by: Qiang Yu
---
src/gallium/auxiliary/util/u_screen.c | 3 +++
src/gallium/include/pipe/p_defines.h | 1 +
src/mesa/state_tracker/st_glsl_to_nir.cpp | 23
Signed-off-by: Qiang Yu
---
src/compiler/Makefile.sources | 1 +
src/compiler/nir/meson.build | 1 +
src/compiler/nir/nir.h| 8 +
.../nir/nir_lower_viewport_transform.c| 142 ++
4 files changed, 152 insertions(
Signed-off-by: Qiang Yu
---
src/mesa/program/prog_statevars.c | 35 +++
src/mesa/program/prog_statevars.h | 2 ++
2 files changed, 37 insertions(+)
diff --git a/src/mesa/program/prog_statevars.c
b/src/mesa/program/prog_statevars.c
index 3bbe451399f..ce74dbe317d 1006
https://bugs.freedesktop.org/show_bug.cgi?id=110240
--- Comment #3 from Jason Ekstrand ---
I can reproduce locally and I think I know what the culpret is. Try reverting
3b3653c4cfbedf55a00cbddd0f341ebd1de81665 on master and see if it fixes it.
--
You are receiving this mail because:
You are th
This is needed in _mesa_fetch_state where scale and translate
are get one by one.
Signed-off-by: Qiang Yu
---
src/mesa/main/viewport.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/src/mesa/main/viewport.c b/src/mesa/main/viewport.c
index 97d328
This is needed by Mali Utgard/Midgard GPU which don't have viewport
transform HW, and Lima/Panfrost driver can share same implementation
in a common place.
I send out this patch series seperatly because Lima is under review in
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/465
and Panfros
https://bugs.freedesktop.org/show_bug.cgi?id=108841
Timothy Arceri changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
To all X.Org Foundation Members:
The X.Org Foundation's annual election is now open and will remain open until
02:00 UTC on 11 April 2019.
Four of the eight director seats are open during this election, with the four
nominees receiving the highest vote totals serving as directors for two year
Reviewed-by:
Also applies to the other patch with or without the suggested change.
On March 26, 2019 17:10:53 Samuel Pitoiset wrote:
It was only propagated when UBO/SSBO access are lowered to offsets.
Signed-off-by: Samuel Pitoiset
---
src/compiler/spirv/vtn_cfg.c | 8 +++---
src/com
You could make the old ones call these. It'd make for a smaller diff and
less code to maintain.
On March 26, 2019 17:10:52 Samuel Pitoiset wrote:
Signed-off-by: Samuel Pitoiset
---
src/compiler/nir/nir_builder.h | 30 ++
1 file changed, 30 insertions(+)
diff --git
Thank you for reviewing the patch.
On 3/26/19 4:46 PM, Matt Turner wrote:
> On Tue, Mar 26, 2019 at 3:35 PM Sagar Ghuge wrote:
>>
>> For the W or UW (signed or unsigned word) source types, the 16-bit value
>> must be replicated in both the low and high words of the 32-bit
>> immediate value.
>>
On Tue, Mar 26, 2019 at 3:35 PM Sagar Ghuge wrote:
>
> For the W or UW (signed or unsigned word) source types, the 16-bit value
> must be replicated in both the low and high words of the 32-bit
> immediate value.
>
> Signed-off-by: Sagar Ghuge
> ---
> src/intel/compiler/brw_fs.cpp | 3 +++
> 1 f
For the W or UW (signed or unsigned word) source types, the 16-bit value
must be replicated in both the low and high words of the 32-bit
immediate value.
Signed-off-by: Sagar Ghuge
---
src/intel/compiler/brw_fs.cpp | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/intel/compiler/brw_fs.
It was only propagated when UBO/SSBO access are lowered to offsets.
Signed-off-by: Samuel Pitoiset
---
src/compiler/spirv/vtn_cfg.c | 8 +++---
src/compiler/spirv/vtn_private.h | 6 +++--
src/compiler/spirv/vtn_variables.c | 42 +-
3 files changed, 32 insert
Signed-off-by: Samuel Pitoiset
---
src/compiler/nir/nir_builder.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/src/compiler/nir/nir_builder.h b/src/compiler/nir/nir_builder.h
index bcf03957bc7..9f9a05cbd09 100644
--- a/src/compiler/nir/nir_builder.h
+++ b/sr
https://bugs.freedesktop.org/show_bug.cgi?id=110141
--- Comment #7 from Adam Jackson ---
(In reply to LoneVVolf from comment #6)
> IF mesa developers feel that these files should be provided by glvnd, then
> it seems logical that mesa devs inform glvnd devs of that position.
My "see also" link
> It doesn't, but the inside of your caching function should probably be
> using it.
Ah, I see, fair point :)
Will we want this caching to be moved up to shared Gallium or no?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.free
https://bugs.freedesktop.org/show_bug.cgi?id=110141
--- Comment #6 from LoneVVolf ---
Before
https://cgit.freedesktop.org/mesa/mesa/commit/?id=b01524fff05eef66e8cd24f1c5aacefed4209f03
mesa built with glvnd support did provide the gles pkgconfig files.
After that commit mesa built with glvnd sup
Alyssa Rosenzweig writes:
>> Can you reuse u_vbuf_get_minmax_index()?
>
> From a preliminary read, it didn't look like that did caching?
It doesn't, but the inside of your caching function should probably be
using it.
signature.asc
Description: PGP signature
___
On Tue, Mar 26, 2019 at 2:44 PM Liu, Leo wrote:
>
> VCN supports this profile as well as UVD, so add it
>
> Signed-off-by: Leo Liu
> CC:
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/radeon/radeon_vcn_dec.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/drivers/
On Mon, 25 Mar 2019 at 21:47, Timothy Arceri wrote:
>
> On 26/3/19 3:43 am, Emil Velikov wrote:
> > Hi Timothy,
> >
> > On Fri, 1 Mar 2019 at 10:36, Timothy Arceri wrote:
> >>
> >> This fixes a segfault when we try to access the array using a
> >> -1 when the array wasn't allocated in the first p
VCN supports this profile as well as UVD, so add it
Signed-off-by: Leo Liu
CC:
---
src/gallium/drivers/radeon/radeon_vcn_dec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/radeon/radeon_vcn_dec.c
b/src/gallium/drivers/radeon/radeon_vcn_dec.c
index a4e6d9dc6b5..d165c5
https://bugs.freedesktop.org/show_bug.cgi?id=110141
--- Comment #5 from Adam Jackson ---
(In reply to Eric Engestrom from comment #2)
> So again, I really don't understand the meaning that's given to "does
> gles2.pc exists?". Am I missing something?
It means "can I link against GLES2's library
https://bugs.freedesktop.org/show_bug.cgi?id=110141
--- Comment #4 from Eric Engestrom ---
(In reply to Daniel Stone from comment #3)
> Mutter, wlroots, Weston, and quite a few others, use egl.pc and glesv2.pc to
> get the cflags/libs/etc for those libraries. It would be great if GLVND
> actually
Quoting Kenneth Graunke (2019-03-26 17:01:57)
> On Tuesday, March 26, 2019 12:16:20 AM PDT Chris Wilson wrote:
> > Quoting Kenneth Graunke (2019-03-26 05:52:10)
> > > On Monday, March 25, 2019 3:58:59 AM PDT Chris Wilson wrote:
> > > > iris currently uses two distinct GEM contexts to have distinct
On Tuesday, March 26, 2019 12:16:20 AM PDT Chris Wilson wrote:
> Quoting Kenneth Graunke (2019-03-26 05:52:10)
> > On Monday, March 25, 2019 3:58:59 AM PDT Chris Wilson wrote:
> > > iris currently uses two distinct GEM contexts to have distinct logical
> > > HW contexts for the compute and render p
https://bugs.freedesktop.org/show_bug.cgi?id=110141
--- Comment #3 from Daniel Stone ---
Mutter, wlroots, Weston, and quite a few others, use egl.pc and glesv2.pc to
get the cflags/libs/etc for those libraries. It would be great if GLVND
actually shipped them.
--
You are receiving this mail bec
https://bugs.freedesktop.org/show_bug.cgi?id=110141
Eric Engestrom changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #2 from Eric Enge
> 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.
Both are being lowered to fne/ine instructions; this hunk is just to
force the second argument
I'm happy to announce that the X.Org Foundation has been chosen to
participate in this year's GSoC program!
Students have from now until April 9th to submit their proposals.
Students will be looking at https://www.x.org/wiki/SummerOfCodeIdeas/ and
https://www.x.org/wiki/ToDo/ for ideas. Please ta
On 03/26/2019 12:44 AM, Dave Airlie wrote:
From: Dave Airlie
This fixes piglit clearbuffer-mixed-format
---
src/gallium/drivers/softpipe/sp_clear.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/softpipe/sp_clear.c
b/src/gallium/drivers/softpipe/sp
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
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 51 ++
1 file changed, 39 insertions(+), 12 deletions(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 88df82dcc54..b35e5659c42 100644
--- a/src/amd/common/ac_
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 48 --
1 file changed, 34 insertions(+), 14 deletions(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index b35e5659c42..508e0da7158 100644
--- a/src/amd/common/ac_
LLVM 9+ now supports 8-bit and 16-bit types.
This changes requires LLVM r356465.
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 51 +++---
1 file changed, 28 insertions(+), 23 deletions(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/co
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_nir_to_llvm.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 2321fed69f3..d74693ddd68 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/s
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index b0ce7fc98bd..bf4fe3d8c64 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 7f6b9df080c..8046d08d300 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 8046d08d300..b0ce7fc98bd 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index bf4fe3d8c64..54d91649614 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/comm
https://bugs.freedesktop.org/show_bug.cgi?id=109939
Alex Smith changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
27670 shaders in 14347 tests
Totals:
SGPRS: 1231173 -> 1236757 (0.45 %)
VGPRS: 866056 -> 867488 (0.17 %)
Spilled SGPRs: 24201 -> 24169 (-0.13 %)
Code Size: 46134836 -> 46115944 (-0.04 %) bytes
Max Waves: 232287 -> 232070 (-0.09 %)
Totals from affected shaders:
SGPRS: 247624 -> 253208 (2.26 %)
VGPR
https://bugs.freedesktop.org/show_bug.cgi?id=102639
--- Comment #3 from peterpen ---
This is my first time to visit here using the url and play this
http://robloxfreerobuxgenerator.com/ online roblox game its really interesting
game here you get the better process for found the roblox game.
--
Quoting Kenneth Graunke (2019-03-26 05:52:10)
> On Monday, March 25, 2019 3:58:59 AM PDT Chris Wilson wrote:
> > iris currently uses two distinct GEM contexts to have distinct logical
> > HW contexts for the compute and render pipelines. However, using two
> > distinct GEM contexts implies that the
46 matches
Mail list logo