The hardware doesn't support rendering to R24_UNORM_X8_TYPELESS, so
Jason decided to fake it with a bit of shader math and R32_UNORM RTs.
The only problem is that R32_UNORM isn't renderable either...so we've
just traded one bad format for another.
This patch makes us use R32_UINT instead.
---
On Fri, Aug 10, 2018 at 9:04 PM, Ian Romanick wrote:
> On 08/07/2018 10:42 PM, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> This is needed for exposing the samplerBuffer functions under
>> EXT_gpu_shader4.
>>
>> glTexBufferEXT is defined in glapi, but "make check" fails.
>> What am I doing
On Fri, Aug 10, 2018 at 9:03 PM, Ian Romanick wrote:
> On 08/07/2018 10:41 PM, Marek Olšák wrote:
>> Hi,
>>
>> This adds EXT_gpu_shader4 with its subset EXT_texture_buffer_object.
>>
>> Some applications that previously required force_glsl_version=130 now
>> work without it, because
On 08/10/2018 06:20 PM, Eric Anholt wrote:
> Now that we have the util function for the default values, we can get rid
> of the boilerplate.
> ---
> src/gallium/auxiliary/util/u_screen.c | 6 +-
> src/gallium/drivers/vc4/vc4_screen.c | 171 --
> 2 files changed, 1
One of the pains of implementing a gallium driver is filling in a million
pipe caps you don't know about yet when you're just starting out. One of
the pains of working on gallium is copy-and-pasting your new PIPE_CAP into
each driver. We can fix both of these by having each driver call into the
Now that we have the util function for the default values, we can get rid
of the boilerplate.
---
.../drivers/freedreno/freedreno_screen.c | 103 +-
1 file changed, 2 insertions(+), 101 deletions(-)
diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c
Now that we have the util function for the default values, we can get rid
of the boilerplate.
---
src/gallium/drivers/v3d/v3d_screen.c | 147 ---
1 file changed, 147 deletions(-)
diff --git a/src/gallium/drivers/v3d/v3d_screen.c
b/src/gallium/drivers/v3d/v3d_screen.c
I've been putting off some PIPE_CAPs I've needed to write because each
one is such a pain to do, so I went and implemented the thing I've
been dreaming of: a single place to define a new pipe cap's default
state.
Eric Anholt (4):
gallium: Add a helper for implementing PIPE_CAP_* default values.
Now that we have the util function for the default values, we can get rid
of the boilerplate.
---
src/gallium/auxiliary/util/u_screen.c | 6 +-
src/gallium/drivers/vc4/vc4_screen.c | 171 --
2 files changed, 1 insertion(+), 176 deletions(-)
diff --git
On 08/07/2018 10:42 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> This is needed for exposing the samplerBuffer functions under
> EXT_gpu_shader4.
>
> glTexBufferEXT is defined in glapi, but "make check" fails.
> What am I doing wrong?
> ---
> docs/relnotes/18.3.0.html | 1 +
>
On 08/07/2018 10:41 PM, Marek Olšák wrote:
> Hi,
>
> This adds EXT_gpu_shader4 with its subset EXT_texture_buffer_object.
>
> Some applications that previously required force_glsl_version=130 now
> work without it, because EXT_gpu_shader4 enables a subset of GLSL 1.30.
>
> There are also
This commit is
Reviewed-by: Ian Romanick
On 08/08/2018 04:55 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> radeonsi wants to report a different value
> ---
> src/compiler/glsl/glsl_parser_extras.cpp | 3 ++-
> src/compiler/glsl/glsl_parser_extras.h | 1 +
> src/mesa/main/context.c
This extension can be supported on SKL+. With this patch,
all corresponding tests (6K+) in CTS can pass. No test fails.
I verified CTS with the command below:
deqp-vk --deqp-case=dEQP-VK.pipeline.sampler.view_type.*reduce*
---
src/intel/vulkan/anv_device.c | 8
On Fri, Aug 10, 2018 at 02:12:55PM -0700, Dylan Baker wrote:
> Quoting Nanley Chery (2018-08-10 10:23:34)
> > Satisfy the BLT engine's row pitch limitation on the destination
> > miptree. The destination miptree is untiled, so its row_pitch will be
> > slightly less than or equal to the source
Rhys Kidd writes:
> Signed-off-by: Rhys Kidd
Does this actually do anything for us, though? Shouldn't we be hooking
up our perf_debug() calls to it?
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
On August 10, 2018 13:25:04 Kenneth Graunke wrote:
On Friday, August 10, 2018 8:34:12 AM PDT Jason Ekstrand wrote:
On August 10, 2018 03:19:18 Kenneth Graunke wrote:
The hardware doesn't support rendering to R24_UNORM_X8_TYPELESS, so
Jason decided to fake it with a bit of shader math and
In both Python 2 and 3, opening a file without specifying the mode will
open it for reading in text mode ('r').
On Python 2, the read() method of a file object opened in mode 'r' will
return byte strings, while on Python 3 it will return unicode strings.
Explicitly specifying the binary mode
Quoting Nanley Chery (2018-08-10 10:23:34)
> Satisfy the BLT engine's row pitch limitation on the destination
> miptree. The destination miptree is untiled, so its row_pitch will be
> slightly less than or equal to the source miptree's row_pitch. Use the
> source miptree's row_pitch in
https://bugs.freedesktop.org/show_bug.cgi?id=107530
--- Comment #5 from Lionel Landwerlin ---
(In reply to Lukas K. from comment #4)
> (In reply to Lionel Landwerlin from comment #1)
> > What window system is GTK+ using? (Wayland/X11)
> X11 1.20.0
> > What's the compositor?
> None, but using
On Fri, Aug 10, 2018 at 8:36 PM, Rhys Perry wrote:
> Yeah, "immediate = false;" looks incorrect.
>
> Looking at nvdisasm and the placement of XMAD's various atoms, it seems it
> can only have 16-bit unsigned immediates, so envydis and the patches
> should probably be updated.
>
> As for how
https://bugs.freedesktop.org/show_bug.cgi?id=107530
--- Comment #4 from Lukas K. ---
(In reply to Lionel Landwerlin from comment #1)
> What window system is GTK+ using? (Wayland/X11)
X11 1.20.0
> What's the compositor?
None, but using compton doesn't change anything.
Seems like this issue is
Yeah, "immediate = false;" looks incorrect.
Looking at nvdisasm and the placement of XMAD's various atoms, it seems it
can only have 16-bit unsigned immediates, so envydis and the patches
should probably be updated.
As for how multiplication by immediates work with mul/mad -> XMAD
conversion,
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_perfcounter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_perfcounter.c
b/src/gallium/drivers/radeonsi/si_perfcounter.c
index 43bf887b774..c4f6e164fb5 100644
---
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_get.c | 49 ++
src/gallium/drivers/radeonsi/si_pipe.c | 2 +-
src/gallium/drivers/radeonsi/si_pipe.h | 1 -
3 files changed, 12 insertions(+), 40 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_get.c
From: Marek Olšák
---
src/amd/common/ac_gpu_info.c | 6 +-
src/amd/common/ac_gpu_info.h | 1 +
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 7 ++-
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git
On Friday, August 10, 2018 8:34:12 AM PDT Jason Ekstrand wrote:
> On August 10, 2018 03:19:18 Kenneth Graunke wrote:
>
> > The hardware doesn't support rendering to R24_UNORM_X8_TYPELESS, so
> > Jason decided to fake it with a bit of shader math and R32_UNORM RTs.
> >
> > The only problem is
From: Marek Olšák
same number as our closed GL driver
v2: don't use MaxArrayLockSize
---
src/mesa/main/config.h | 3 +++
src/mesa/main/get_hash_params.py | 4 ++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/config.h b/src/mesa/main/config.h
index
On 10 August 2018 at 13:25, Martin Fuzzey wrote:
> Hi Christian,
>
> On 01/08/18 23:07, Christian Gmeiner wrote:
>>
>> Add an improved drmOpenWithType(..) clone which fixes some serious
>> flaws. Some highlights:
>> - using busid works only with PCI devices
>> - open() w/o O_CLOEXEC
>> -
Move this now-unused function into the existing comment block, which was its
only prior use.
../../../../../src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp:2645:1:
warning:
unused function 'partitionLoadStore' [-Wunused-function]
partitionLoadStore(uint8_t comp[2], uint8_t
On Fri, Aug 10, 2018 at 05:37:12PM +0100, Lionel Landwerlin wrote:
> Andrey also opened a bug about this issue :
> https://bugs.freedesktop.org/show_bug.cgi?id=107544
>
> It feels like it should be fixed on master though. get_length() shouldn't
> return -1 for structs anymore.
> We should
Fix rendering issues on BDW and SKL.
Fixes 0288fe8d0417730bdd5b3477130dd1dc32bdbcd3
("i965/miptree: Use the correct BLT pitch")
Fixes the following regressions seen
exclusively on SKL:
* KHR-GL46.texture_barrier_ARB.disjoint-texels
* KHR-GL46.texture_barrier_ARB.overlapping-texels
*
Satisfy the BLT engine's row pitch limitation on the destination
miptree. The destination miptree is untiled, so its row_pitch will be
slightly less than or equal to the source miptree's row_pitch. Use the
source miptree's row_pitch in can_blit_slice instead of its blt_pitch.
Fixes
Hi list,
Due to a busy week and a slip of my mind I didn't get out the announcement for
18.1.6 on Wednesday. Therefore, I'm planning to make the release Monday August
13th, at or around 10AM PDT.
It's been another busy cycle for 18.1, currently we have:
- 40 Queued
- 0 Nominated
- 0 Rejected
Signed-off-by: Rhys Kidd
---
src/gallium/drivers/v3d/v3d_context.c | 13 +
src/gallium/drivers/v3d/v3d_context.h | 1 +
2 files changed, 14 insertions(+)
diff --git a/src/gallium/drivers/v3d/v3d_context.c
b/src/gallium/drivers/v3d/v3d_context.c
index 2fd2fa0bbf..0737713e8b 100644
Signed-off-by: Rhys Kidd
---
src/gallium/drivers/vc4/vc4_context.c | 13 +
src/gallium/drivers/vc4/vc4_context.h | 1 +
2 files changed, 14 insertions(+)
diff --git a/src/gallium/drivers/vc4/vc4_context.c
b/src/gallium/drivers/vc4/vc4_context.c
index 9ff39c2655..6f91d0567c 100644
Andrey also opened a bug about this issue :
https://bugs.freedesktop.org/show_bug.cgi?id=107544
It feels like it should be fixed on master though. get_length()
shouldn't return -1 for structs anymore.
We should probably return 1 at end of get_length() so that the decoder
prints out "unknown
I don't think so.
On Wed, Aug 8, 2018 at 11:27 PM, Karol Herbst wrote:
> On Mon, Jul 23, 2018 at 12:40 PM, Rhys Perry wrote:
>> Signed-off-by: Rhys Perry
>> ---
>> src/gallium/drivers/nouveau/codegen/nv50_ir.h | 26
>> ++
>>
On Thu, Aug 09, 2018 at 03:00:30PM +0300, andrey simiklit wrote:
> Hi,
>
> Sorry I missed the main thought here.
> The "gen_group_get_length" function returns int
> but the "iter_group_offset_bits" function returns uint32_t
> So uint32_t(int(-32)) = 0xFFE0U and it looks like unexpected
On August 9, 2018 07:44:51 Alejandro Piñeiro wrote:
After commit "nir: Use derefs in nir_lower_samplers"
(75286c2d083cdbdfb202a93349e567df0441d5f7) assumes one deref for both
the texture and the sampler. However there are cases (on OpenGL, using
ARB_gl_spirv) where SPIR-V is not providing a
On August 10, 2018 03:19:18 Kenneth Graunke wrote:
The hardware doesn't support rendering to R24_UNORM_X8_TYPELESS, so
Jason decided to fake it with a bit of shader math and R32_UNORM RTs.
The only problem is that R32_UNORM isn't renderable either...so we've
just traded one bad format for
https://bugs.freedesktop.org/show_bug.cgi?id=107530
--- Comment #3 from Marina Chernish ---
Created attachment 141038
--> https://bugs.freedesktop.org/attachment.cgi?id=141038=edit
OpenGL area
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact
https://bugs.freedesktop.org/show_bug.cgi?id=107530
--- Comment #2 from Marina Chernish ---
Hi Lukas,
I've tried to reproduce it on following configuration:
OS: Linux ubuntu 4.15.0-29-generic #31-Ubuntu SMP Tue Jul 17 15:39:52 UTC 2018
x86_64 x86_64 x86_64 GNU/Linux
Device: Mesa DRI Intel(R)
Reviewed-by: Roland Scheidegger
Am 10.08.2018 um 15:04 schrieb Gert Wollny:
> From: Gert Wollny
>
> The GLSL operations findLSB, findMSB, and countBits always return
> a signed integer type. Let TGSI reflect this.
>
> v2: Properly set values in infer_(src|dst)_type (Thanks Roland
>
https://bugs.freedesktop.org/show_bug.cgi?id=107530
Lionel Landwerlin changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #1 from
Hi Marek,
On Thursday, 9 August 2018 01:55:11 CEST Marek Olšák wrote:
> From: Marek Olšák
>
> same number as our closed GL driver
> ---
> src/mesa/main/config.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/main/config.h b/src/mesa/main/config.h
> index
Used internally in freedreno/ir3 for the vec2 value that hw passes to
shader to use as coordinate for bary.f (varying fetch) instruction.
This is not the same as SYSTEM_VALUE_FRAG_COORD.
Signed-off-by: Rob Clark
---
Up until now, we'd been hard-coding the location of this value (ie. to
r0.xy),
Maybe set out_filename = NULL (might not be initialized on Linux by
default, according to manpage).
Either way :
Reviewed-by: Lionel Landwerlin
On 10/08/18 13:21, Eric Engestrom wrote:
Compiler wasn't happy about strncpy() depending on the source's length and not
the target's, but this whole
From: Gert Wollny
The GLSL operations findLSB, findMSB, and countBits always return
a signed integer type. Let TGSI reflect this.
v2: Properly set values in infer_(src|dst)_type (Thanks Roland
Schneidegger for pointing out problems with my 1st approach)
v2: Set values in the common
()
On Tue, Jul 24, 2018 at 9:00 AM Jonathan Marek wrote:
>
> this patch brings a number of changes to ir2:
> -ir2 now generates CF clauses as necessary during assembly. this simplifies
> fd2_program/fd2_compiler and is necessary to implement optimization passes
> -ir2 now has separate
Hi Christian,
On 01/08/18 23:07, Christian Gmeiner wrote:
Add an improved drmOpenWithType(..) clone which fixes some serious
flaws. Some highlights:
- using busid works only with PCI devices
- open() w/o O_CLOEXEC
- when build w/o udev - it creates a node: mkdir, chown(root), chmod, mknod
Compiler wasn't happy about strncpy() depending on the source's length and not
the target's, but this whole thing can be simplified by simply using asprintf()
(which is already used in this file, so no #include necessary).
run.c: In function ‘main._omp_fn.0’:
run.c:964:21: warning: ‘strncpy’
Hi Ville,
> Looks like
> "vid_gl20" "0"
> is needed to reproduce the issue.
Thanks! Now I can observe the problem!
And the attached patch seems to fix what I can observe here.
Does the attached patch also fix the problem with the
older intel chip you originally reported?
Thanks!
MathiasFrom
https://bugs.freedesktop.org/show_bug.cgi?id=106833
--- Comment #7 from Yang Gu ---
Yang is OOO from Aug 10 to 19. Please expect slow response.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=106833
Tapani Pälli changed:
What|Removed |Added
Attachment #140052|0 |1
is obsolete|
One of the reasons we didn't notice that R24_UNORM_X8_TYPELESS
destinations were broken was that an earlier layer was swapping it
out for B8G8R8A8_UNORM. That made Z24X8 -> Z24X8 blits work.
However, R32_FLOAT -> R24_UNORM_X8_TYPELESS was still totally broken.
The old code only considered one
The hardware doesn't support rendering to R24_UNORM_X8_TYPELESS, so
Jason decided to fake it with a bit of shader math and R32_UNORM RTs.
The only problem is that R32_UNORM isn't renderable either...so we've
just traded one bad format for another.
This patch makes us use R32_UINT instead.
---
Hi Jason, I'm CCing you for this one as you basically provided the
pseudocode I used as reference. So I assume that you already know what's
going on, hoping that would make the review easier.
On 09/08/18 15:43, Alejandro Piñeiro wrote:
> After commit "nir: Use derefs in nir_lower_samplers"
>
On Thursday, 2018-08-09 10:32:35 -0700, Dylan Baker wrote:
> Quoting Eric Engestrom (2018-08-09 08:36:55)
> > On Monday, 2018-08-06 17:50:48 -0700, Dylan Baker wrote:
> > > ---
> > > meson.build | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/meson.build
https://bugs.freedesktop.org/show_bug.cgi?id=107524
--- Comment #3 from Matwey V. Kornilov ---
Created attachment 141033
--> https://bugs.freedesktop.org/attachment.cgi?id=141033=edit
shader_run test
Attached is what are you looking for.
It passes at Intel and fails at llvmpipe.
--
You are
Okay, got it, thank you for your verification
On 8/10/2018 2:15 PM, Tapani Pälli wrote:
> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Tapani P?lli
> Sent: Friday, August 10, 2018 2:15 PM
> To: Zhaowei Yuan;
Ping.
Regards,
Qiang
From: Qiang Yu
Sent: Monday, August 6, 2018 11:19:21 AM
To: mesa-dev@lists.freedesktop.org
Cc: Adam Jackson; Michel Dänzer; Eric Engestrom; Emil Velikov; Yu, Qiang
Subject: [PATCH v3 0/6] support config for third-party DRI driver
Hi;
On 08/10/2018 09:08 AM, Zhaowei Yuan wrote:
Thank you for reminding me of the mistakes, I'll re-commit a PATCH v3,
thanks
However, I've re-tested those failed cases with latest code on master branch
and got the same result. I don't why you didn't see anything wrong on your
board,
it
Thank you for reminding me of the mistakes, I'll re-commit a PATCH v3,
thanks
However, I've re-tested those failed cases with latest code on master branch
and got the same result. I don't why you didn't see anything wrong on your
board,
it doesn't make sense.
On 08/07/2018 5:58 PM, Tapani Pälli
63 matches
Mail list logo
