Thanks for your guys' information, although it's much deeper than my
question and also my understanding of the NIR and compiler knowledge.
This patch fix my problem:
https://patchwork.freedesktop.org/patch/268946/
But seems it's not the final solution, right? And I'm not sure if we will
have other
Timothy Arceri writes:
> The functional change here is moving the nir_lower_io_to_scalar_early()
> calls inside st_nir_link_shaders() and moving the st_nir_opts() call
> after the call to nir_lower_io_arrays_to_elements().
>
> This fixes a bug with the following piglit test due to the current cod
On Fri, Jan 4, 2019 at 5:04 PM Ilia Mirkin wrote:
>
> On Fri, Jan 4, 2019 at 4:56 PM Kevin Strasser
> wrote:
> > diff --git a/src/mesa/drivers/dri/common/utils.c
> > b/src/mesa/drivers/dri/common/utils.c
> > index b52c59f..1cf9362 100644
> > --- a/src/mesa/drivers/dri/common/utils.c
> > +++ b/s
On Fri, Jan 4, 2019 at 4:56 PM Kevin Strasser wrote:
> diff --git a/src/mesa/drivers/dri/common/utils.c
> b/src/mesa/drivers/dri/common/utils.c
> index b52c59f..1cf9362 100644
> --- a/src/mesa/drivers/dri/common/utils.c
> +++ b/src/mesa/drivers/dri/common/utils.c
> @@ -200,6 +200,10 @@ driCreateC
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
Needed for allocating buffers with pixel formats wider than 32 bpp.
Signed-off-by: Kevin Strasser
---
src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
b/src/gallium/winsys/sw/k
Add dri image formats for RGBA ordered 64 bpp IEEE 754 half precision
floating point.
Introduce a new dri configuration option so users can diable exposure of
fp16 formats, following the same design and policy of rgb10a2 (opt-in
for i965 and opt-out for gallium).
Add a loader cap field so loaders
Populate __DRI_ATTRIB_FLOAT_BIT, such that we can filter for formats
containing floating point pixel data and egl/glx can satisfy the
requirements for their respective extensions.
Signed-off-by: Kevin Strasser
---
src/egl/drivers/dri2/egl_dri2.c | 2 ++
src/egl/drivers/dri2/platform_drm.c |
Set loader caps indicating that gbm can handle both rgba ordering and
fp16 formats.
Signed-off-by: Kevin Strasser
---
src/gbm/backends/dri/gbm_dri.c | 26 +-
src/gbm/main/gbm.c | 3 +++
src/gbm/main/gbm.h | 9 +
3 files changed, 37 insert
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 | 8
1 file changed, 8 insertions(+)
diff --git a/incl
The dri core api was written with the assumption that all attribute values
would fit into 32 bits. This limitation means the config handlers can't
accept 64 bpp formats. Reserve 64 bits for rgba masks and add new
attributes that allow access to the upper 32 bits.
Signed-off-by: Kevin Strasser
---
Various recreation scenarios lead to API thread getting stuck in
swr_fence_finish(). This is a multi-context issue, whereby one context
overwrites the fence read-value with a previous sync's lesser value.
The fence sync value is supposed to be always increasing.
In swr_fence_cb(), only update the
On Fri, Jan 04, 2019 at 01:07:07PM -0600, Jason Ekstrand wrote:
> In 92eb5bbc68d7324 we attempted to avoid copying clear colors whenever
> we weren't doing a resolve. However, this broke MSAA resolves because
> we need the clear color in the source. This patch makes blorp much more
> conservative
In 92eb5bbc68d7324 we attempted to avoid copying clear colors whenever
we weren't doing a resolve. However, this broke MSAA resolves because
we need the clear color in the source. This patch makes blorp much more
conservative such that it only avoids the clear color copy if either
aux_usage == NO
On Fri, Jan 4, 2019 at 10:46 AM Jason Ekstrand wrote:
>
> On Fri, Jan 4, 2019 at 4:07 AM Erik Faye-Lund
> wrote:
>>
>> On Thu, 2019-01-03 at 11:58 -0600, Jason Ekstrand wrote:
>> > On Thu, Jan 3, 2019 at 3:39 AM Erik Faye-Lund <
>> > erik.faye-l...@collabora.com> wrote:
>> > > On Wed, 2019-01-02
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Bug 99553 depends on bug 102009, which changed state.
Bug 102009 Summary: [clover, amdgcn] Blender crashes when compiling OpenCL
kernel
https://bugs.freedesktop.org/show_bug.cgi?id=102009
What|Removed |Added
--
https://bugs.freedesktop.org/show_bug.cgi?id=102009
Jan Vesely changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Bug 99553 depends on bug 102009, which changed state.
Bug 102009 Summary: [clover, amdgcn] Blender crashes when compiling OpenCL
kernel
https://bugs.freedesktop.org/show_bug.cgi?id=102009
What|Removed |Added
--
https://bugs.freedesktop.org/show_bug.cgi?id=102009
Markus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Fri, Jan 4, 2019 at 4:07 AM Erik Faye-Lund
wrote:
> On Thu, 2019-01-03 at 11:58 -0600, Jason Ekstrand wrote:
> > On Thu, Jan 3, 2019 at 3:39 AM Erik Faye-Lund <
> > erik.faye-l...@collabora.com> wrote:
> > > On Wed, 2019-01-02 at 10:16 -0600, Jason Ekstrand wrote:
> > > > On Wed, Jan 2, 2019 a
Please add some commit messages. With that, the patch is
Reviewed-by: Leo Liu
On 1/3/19 5:20 AM, Das, Indrajit-kumar wrote:
> From: Indrajit Das
> Date: Thu, 3 Jan 2019 14:36:33 +0530
> Subject: [PATCH] st/va: Return correct status from vlVaQuerySurfaceStatus
>
> Signed-off-by: Indrajit Das
>
https://bugs.freedesktop.org/show_bug.cgi?id=107115
Jan Vesely changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Jan Vesely changed:
What|Removed |Added
Depends on||109224
Referenced Bugs:
https://bugs.free
https://bugs.freedesktop.org/show_bug.cgi?id=87738
Jan Vesely changed:
What|Removed |Added
Blocks||109224
Referenced Bugs:
https://bugs.free
On Thu, 2019-01-03 at 11:58 -0600, Jason Ekstrand wrote:
> On Thu, Jan 3, 2019 at 3:39 AM Erik Faye-Lund <
> erik.faye-l...@collabora.com> wrote:
> > On Wed, 2019-01-02 at 10:16 -0600, Jason Ekstrand wrote:
> > > On Wed, Jan 2, 2019 at 9:43 AM Ilia Mirkin
> > > wrote:
> > > > Have a look at the fi
On Fri, 2019-01-04 at 02:02 -0800, Francisco Jerez wrote:
> Iago Toral writes:
>
> > On Wed, 2019-01-02 at 15:00 -0800, Francisco Jerez wrote:
> > > Iago Toral Quiroga writes:
> > >
> > > > There are hardware restrictions to consider that seem to affect
> > > > atom platforms
> > > > only.
> >
Iago Toral writes:
> On Wed, 2019-01-02 at 15:00 -0800, Francisco Jerez wrote:
>> Iago Toral Quiroga writes:
>>
>> > There are hardware restrictions to consider that seem to affect
>> > atom platforms
>> > only.
>>
>> Same comment here as for PATCH 13 of this series. This and PATCH 40
>> shou
Iago Toral writes:
> On Sat, 2018-12-29 at 12:39 -0800, Francisco Jerez wrote:
>> This legalization pass is meant to handle situations where the source
>> or destination regioning controls of an instruction are unsupported
>> by
>> the hardware and need to be lowered away into separate instructio
On Sat, 2018-12-29 at 12:39 -0800, Francisco Jerez wrote:
> This legalization pass is meant to handle situations where the source
> or destination regioning controls of an instruction are unsupported
> by
> the hardware and need to be lowered away into separate instructions.
> This should be more r
On Wed, 2019-01-02 at 15:00 -0800, Francisco Jerez wrote:
> Iago Toral Quiroga writes:
>
> > There are hardware restrictions to consider that seem to affect
> > atom platforms
> > only.
>
> Same comment here as for PATCH 13 of this series. This and PATCH 40
> shouldn't be necessary anymore with
30 matches
Mail list logo
