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: only for 32 bit operations
>
https://bugs.freedesktop.org/show_bug.cgi?id=94747
--- Comment #5 from Ian Romanick ---
In the original message I neglected to mention any specific shader that
exhibited this issue. Allow me to remedy that:
shaders/closed/unigine/superposition/high/5392.shader_test. This shader
generates a
https://bugs.freedesktop.org/show_bug.cgi?id=109229
Timothy Arceri changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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 of the switch
handle OP_SAT with modifiers
v3: only for
Changes since:
* v11: Fix compilation error introduced in v11.
* v10:
- Reuse format_validation_msg in is_valid_spirv.
- Remove LVL2STR macro in format_validation_msg.
* v9: Add `clover_cpp_std` to the overrides of the `libclspirv` target
in Meson.
* v7: Add DEFINES to libclspirv and
On Mon, Jan 28, 2019 at 2:29 PM Ilia Mirkin wrote:
>
> 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
Quoting Adam Jackson (2019-01-28 09:00:13)
> On Sat, 2019-01-26 at 13:56 +0100, Patrick Steinhardt wrote:
>
> > Unfortunately, I'm not aware of any easy way to do this. The
> > problem is not due to the compiler, as the program compiles and
> > links just fine with musl libc. Instead, this is a
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
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 of the switch
handle OP_SAT with modifiers
v3: only for
https://bugs.freedesktop.org/show_bug.cgi?id=109488
Mark Janes changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |matts...@gmail.com
|org
https://bugs.freedesktop.org/show_bug.cgi?id=109488
Bug ID: 109488
Summary: Mesa 18.3.2 crash on a specific fragment shader
(assert triggered) / already fixed on the master
branch.
Product: Mesa
Version: 18.3
On Sat, Jan 26, 2019 at 05:22:06PM +0200, Eleni Maria Stea wrote:
> Hi Nanley,
>
> On Fri, 18 Jan 2019 15:32:02 -0800
> Nanley Chery wrote:
>
>
> > > diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > > b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c index
> > >
On Mon, Jan 28, 2019 at 1:15 PM Eric Anholt wrote:
>
> Marek Olšák writes:
>
> > Hi,
> >
> > People don't prefix merge request names with the component they are
> > changing, so unrelated people have to open merge requests they don't really
> > want to look at.
> >
> > Could you start adding the
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
I don't see labels in Gmail.
Marek
On Mon, Jan 28, 2019 at 1:15 PM Eric Anholt wrote:
> Marek Olšák writes:
>
> > Hi,
> >
> > People don't prefix merge request names with the component they are
> > changing, so unrelated people have to open merge requests they don't
> really
> > want to look
indexConfigAttrib iterates over every index in the dri driver, possibly
exceeding __DRI_ATTRIB_MAX. In other words, if the dri driver has newer
attributes libEGL will end up reading from uninitialized memory through
dri2_to_egl_attribute_map[].
Signed-off-by: Kevin Strasser
Cc:
In the case that __DRI_ATTRIB_FLOAT_BIT is set in the dri config, set
EGL_COLOR_COMPONENT_TYPE_FLOAT_EXT in the egl config. Add a field to each
platform driver visual to indicate if it has components that are in floating
point form.
Signed-off-by: Kevin Strasser
---
Add 64 bpp 16:16:16:16 half float pixel formats. Each 16 bit component is
formatted in IEEE-754 half-precision float (binary16) 1:5:10
MSb-sign:exponent:fraction form.
Signed-off-by: Kevin Strasser
---
include/drm-uapi/drm_fourcc.h | 9 +
1 file changed, 9 insertions(+)
diff --git
This series enables fp16 fbconfigs and visuals by leveraging existing
off-screen rendering support.
These formats can be used in conjunction with EXT_surface_SMPTE2086_metadata
(not yet implemented by any drivers) to support EXT_gl_colorspace_scrgb /
EXT_gl_colorspace_scrgb_linear, used in places
glx doesn't read the masks from the dri config directly, but for consistency
add shifts to the glxconfig.
Signed-off-by: Kevin Strasser
---
src/glx/dri_common.c | 4
src/glx/glxconfig.h | 1 +
2 files changed, 5 insertions(+)
diff --git a/src/glx/dri_common.c b/src/glx/dri_common.c
index
The existing mask attributes can only support up to 32 bpp. Introduce
per-channel SHIFT attributes that indicate how many bits, from lsb towards
msb, the bit field is offset. A shift of -1 will indicate that there is no
bit field set for the channel.
As old loaders will still be looking for
Add dri formats for RGBA ordered 64 bpp IEEE 754 half precision floating
point. Leverage existing offscreen render support for
MESA_FORMAT_RGBA_FLOAT16 and MESA_FORMAT_RGBX_FLOAT16.
Signed-off-by: Kevin Strasser
---
include/GL/internal/dri_interface.h| 4
Change dri2_add_config to accept an array of shifts instead of masks, and
compare with those set in the dri config. Convert all platform driver masks
to shifts.
In order to handle older drivers, where shift attributes aren't available,
we fall back to the mask attributes and compute the shifts
Introduce a new dri configuration option so users can disable exposure of
fp16 formats, following the same design and policy of rgb10a2 (opt-in for
i965 and opt-out for gallium).
Also, add a loader cap field so loaders can indicate if they know how to
handle fp16 formats.
Signed-off-by: Kevin
Set loader caps indicating that wayland can handle both rgba ordering and
fp16 formats.
NOTE: This requries libwayland to provide definitions for
WL_SHM_FORMAT_XBGR16161616F and WL_SHM_FORMAT_ABGR16161616F
Signed-off-by: Kevin Strasser
---
src/egl/drivers/dri2/platform_wayland.c | 30
In order to handle pixel formats that consist of floating point data, enable
floatMode field in the dri config, and set __DRI_ATTRIB_FLOAT_BIT in the
render type attribute.
Signed-off-by: Kevin Strasser
---
src/mesa/drivers/dri/common/utils.c | 5 +
1 file changed, 5 insertions(+)
diff
Set loader caps indicating that gbm can handle both rgba ordering and fp16
formats.
Signed-off-by: Kevin Strasser
---
src/egl/drivers/dri2/egl_dri2.c | 2 ++
src/gbm/backends/dri/gbm_dri.c | 26 +-
src/gbm/main/gbm.c | 3 +++
src/gbm/main/gbm.h
Expose configs when allow_fp16_configs has been enabled and
DRI_LOADER_CAP_FP16 is set in the loader.
Also, make kms_swrast_dri respect format bpp, to allow for allocating
buffers wider than 32 bpp.
Signed-off-by: Kevin Strasser
---
src/gallium/state_trackers/dri/dri2.c | 22
Expose configs when allow_fp16_configs has been enabled and
DRI_LOADER_CAP_FP16 is set in the loader.
Signed-off-by: Kevin Strasser
---
src/mesa/drivers/dri/i965/intel_screen.c | 38 +---
1 file changed, 35 insertions(+), 3 deletions(-)
diff --git
On Mon, Jan 28, 2019 at 10:25 AM Roland Scheidegger wrote:
>
> I like it :-).
> That said, there's some caveats as discussed on IRC - in particular for
> gpus which don't do round-to-nearest-even for ordinary fp64 math (or
> rounding mode could be set to something else manually) it won't do the
>
I like it :-).
That said, there's some caveats as discussed on IRC - in particular for
gpus which don't do round-to-nearest-even for ordinary fp64 math (or
rounding mode could be set to something else manually) it won't do the
right thing.
And if you can have fast-math enabled, then it probably
Marek Olšák writes:
> Hi,
>
> People don't prefix merge request names with the component they are
> changing, so unrelated people have to open merge requests they don't really
> want to look at.
>
> Could you start adding the component prefix like we do for commits?
Not sure if you've noticed,
Hi,
People don't prefix merge request names with the component they are
changing, so unrelated people have to open merge requests they don't really
want to look at.
Could you start adding the component prefix like we do for commits?
Thanks,
Marek
___
Eric Anholt writes:
> [ Unknown signature status ]
> Rob Herring writes:
>
>> If we can't find a driver matching by name, then use the kmsro driver.
>> This removes the need for needing a driver descriptor for every possible
>> KMS driver.
>>
>> Signed-off-by: Rob Herring
>
> I've pushed patch
Rob Herring writes:
> If we can't find a driver matching by name, then use the kmsro driver.
> This removes the need for needing a driver descriptor for every possible
> KMS driver.
>
> Signed-off-by: Rob Herring
I've pushed patch 1 and 2, and the hx8357d rebase.
signature.asc
Description:
Use the trick of adding and then subtracting 2**52 (52 is the number of
explicit mantissa bits a double-precision floating-point value has) to
implement round-to-even.
Cuts the number of instructions on SKL of the piglit test
fs-roundEven-double.shader_test from 109 to 21.
---
Erik Faye-Lund writes:
> On Fri, 2019-01-25 at 13:41 -0800, Eric Anholt wrote:
>> Nick Kreeger writes:
>>
>> > The OES_texture* extensions for float and half-float are valid when
>> > GLES2 is present w/ the matching
>> > OES_texture_float/OES_texture_half_float extensions. This fix
>> >
On 1/28/19 5:58 PM, Bas Nieuwenhuizen wrote:
On Fri, Jan 25, 2019 at 5:27 PM Samuel Pitoiset
wrote:
This is needed in order to inline some push constants when possible.
This also adds a new helper for initializing the pass.
Signed-off-by: Samuel Pitoiset
---
On Sat, 2019-01-26 at 13:56 +0100, Patrick Steinhardt wrote:
> Unfortunately, I'm not aware of any easy way to do this. The
> problem is not due to the compiler, as the program compiles and
> links just fine with musl libc. Instead, this is a runtime issue
> that happens when dlopen'ing shared
On Fri, Jan 25, 2019 at 5:27 PM Samuel Pitoiset
wrote:
>
> This is needed in order to inline some push constants when possible.
> This also adds a new helper for initializing the pass.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_nir_to_llvm.c | 2 ++
>
Well, if it looks good to you and you could reproduce before
Reviewed-by: Bas Nieuwenhuizen
On Mon, Jan 28, 2019 at 5:38 PM Samuel Pitoiset
wrote:
>
> This has been disabled some months ago because it introduced
> rendering issues with Shadow Of Warrier II (DXVK). This game is
> no longer
This has been disabled some months ago because it introduced
rendering issues with Shadow Of Warrier II (DXVK). This game is
no longer affected, I wonder if 824cfc1ee5e ("radv: rework the
TC-compat HTILE hardware bug with COND_EXEC") fixed the problem.
I checked The Forest on my Polaris, and it
Reviewed-by: Alex Deucher
On Mon, Jan 28, 2019 at 10:56 AM Marek Olšák wrote:
>
> From: Marek Olšák
>
> ---
> src/amd/common/ac_llvm_util.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/amd/common/ac_llvm_util.c b/src/amd/common/ac_llvm_util.c
> index
From: Marek Olšák
---
src/amd/common/ac_llvm_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/common/ac_llvm_util.c b/src/amd/common/ac_llvm_util.c
index 174a37f22f8..69446863b95 100644
--- a/src/amd/common/ac_llvm_util.c
+++ b/src/amd/common/ac_llvm_util.c
@@
On Sun, Jan 27, 2019 at 1:33 PM Daniel Stone wrote:
>
> Hi,
>
> On Fri, 25 Jan 2019 at 23:24, Rob Clark wrote:
> > (Hmm, I guess I should take a look at what sort of API gitlab offers,
> > but that will probably have to wait until after the branchpoint.. tbh
> > I'd actually be pretty happy w/ a
On Mon, Jan 28, 2019 at 3:32 AM Eduardo Lima Mitev wrote:
>
> On 1/26/19 12:42 AM, Rob Clark wrote:
> > On Fri, Jan 25, 2019 at 10:48 AM Eduardo Lima Mitev
> > wrote:
> >>
> >> There are a bunch of instructions emitted on ir3_compiler_nir related to
> >> offset computations for IO opcodes
Reviewed-by: Bas Nieuwenhuizen
for the series.
On Fri, Jan 25, 2019 at 9:19 AM Samuel Pitoiset
wrote:
>
> Instead of using this useless array_params_mask variable.
> This should set these two attributes to streamout buffers too.
>
> Signed-off-by: Samuel Pitoiset
> ---
>
On Fri, Jan 25, 2019 at 01:16:30PM -0800, Eric Anholt wrote:
> Patrick Steinhardt writes:
>
> > The musl libc library does not have any support for the
> > "initial-exec" TLS model and is unlikely to ever implement it.
> > Thus, TLS support in GLX has been turned off in musl-based
> >
Hi Lucas,
Am Fr., 25. Jan. 2019 um 17:02 Uhr schrieb Lucas Stach :
>
> Hi Christian,
>
> Am Montag, den 21.01.2019, 07:50 +0100 schrieb Christian Gmeiner:
> > If the GPU supports linear sampling, linear addressing mode
> > will be used as default.
> >
> > > Signed-off-by: Christian Gmeiner
> >
On 1/28/19 10:16 AM, Eduardo Lima Mitev wrote:
> On 1/28/19 9:56 AM, Bas Nieuwenhuizen wrote:
>> On Mon, Jan 28, 2019 at 9:38 AM Eduardo Lima Mitev wrote:
>>>
>>> On 1/26/19 5:34 PM, Jason Ekstrand wrote:
Mind suffixing it with _ir3 or something since it's a back-end-specific
intrinsic?
On Fri, 2019-01-25 at 13:41 -0800, Eric Anholt wrote:
> Nick Kreeger writes:
>
> > The OES_texture* extensions for float and half-float are valid when
> > GLES2 is present w/ the matching
> > OES_texture_float/OES_texture_half_float extensions. This fix
> > ensures
> > that these formats are
On 1/28/19 9:56 AM, Bas Nieuwenhuizen wrote:
> On Mon, Jan 28, 2019 at 9:38 AM Eduardo Lima Mitev wrote:
>>
>> On 1/26/19 5:34 PM, Jason Ekstrand wrote:
>>> Mind suffixing it with _ir3 or something since it's a back-end-specific
>>> intrinsic? Incidentally, this looks a lot like
On Fri, 2019-01-25 at 12:54 -0800, Francisco Jerez wrote:
> Iago Toral writes:
>
> > On Thu, 2019-01-24 at 11:45 -0800, Francisco Jerez wrote:
> > > Iago Toral writes:
> > >
> > > > On Wed, 2019-01-23 at 06:03 -0800, Francisco Jerez wrote:
> > > > > Iago Toral Quiroga writes:
(...)
> > >
On Mon, Jan 28, 2019 at 9:38 AM Eduardo Lima Mitev wrote:
>
> On 1/26/19 5:34 PM, Jason Ekstrand wrote:
> > Mind suffixing it with _ir3 or something since it's a back-end-specific
> > intrinsic? Incidentally, this looks a lot like load_image_param_intel.
> >
>
> Yes, I felt inclined to add the
Hi,
On Wed, Jan 16, 2019 at 12:14:43PM +0100, Lucas Stach wrote:
> Am Samstag, den 12.01.2019, 22:22 +0100 schrieb Marek Vasut:
> > > From: Christian Gmeiner
> >
> > A pipe_resource can be shared by all the pipe_context's hanging off the
> > same pipe_screen.
> >
> > > Signed-off-by: Christian
Hi,
just style nits:
On Sat, Jan 12, 2019 at 10:22:20PM +0100, Marek Vasut wrote:
> From: Christian Gmeiner
>
> A pipe_resource can be shared by all the pipe_context's hanging off the
> same pipe_screen.
>
> Signed-off-by: Christian Gmeiner
> Signed-off-by: Marek Vasut
> To:
On 1/26/19 5:34 PM, Jason Ekstrand wrote:
> Mind suffixing it with _ir3 or something since it's a back-end-specific
> intrinsic? Incidentally, this looks a lot like load_image_param_intel.
>
Yes, I felt inclined to add the suffix but wasn't sure how good/bad a
practice it is, so I deferred it
On 1/26/19 12:42 AM, Rob Clark wrote:
> On Fri, Jan 25, 2019 at 10:48 AM Eduardo Lima Mitev wrote:
>>
>> There are a bunch of instructions emitted on ir3_compiler_nir related to
>> offset computations for IO opcodes (ssbo, image, etc). This small series
>> explores the possibility of moving these
Hello Eric or Tapani (or anybody else working on the Intel driver),
I wonder whether one of you could give me an R-B for the Intel patch
[1] in this MR [2]. As far as I can see your CI [3] shows only
unrelated changes.
many thanks,
Gert
[1]
59 matches
Mail list logo
