Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_cs.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_cs.c
b/src/mesa/drivers/dri/i965/brw_cs.c
index 0ab9ebd..9345ce8 100644
--- a/src/mesa/drivers/dri/i965/brw_cs.c
+++ b/src/m
This allows us to first generate atomic operations for shared
variables using these opcodes, and then later we can lower those to
the shared atomics intrinsics with nir_lower_io.
Signed-off-by: Jordan Justen
---
src/compiler/nir/nir_intrinsics.h | 27 +++
1 file changed,
Prevents:
../../../../../src/compiler/nir/nir.h:176:30: warning:
'nir_variable::nir_variable_data::mode' is too small to hold all values of
'enum nir_variable_mode'
nir_variable_mode mode:4;
Signed-off-by: Jordan Justen
---
src/compiler/nir/nir.h | 2 +-
1 file changed, 1 insertion(+),
This patchset allows nir to support shared variable. It works well
with our SPIR-V support in the Intel Vulkan driver.
I've also tried to get GLSL to delay shared variable lowering to allow
it to be handled later in nir, but I got caught up in various places
within the GLSL compiler. Oh well... gi
Previously we were receiving shared variable accesses via a lowered
intrinsic function from glsl. This change allows us to send in
variables instead. For example, when converting from SPIR-V.
Signed-off-by: Jordan Justen
---
src/compiler/nir/nir.c | 6 ++
src/compiler/nir/nir.h
If the glsl compiler option LowerShaderSharedVariables is set, then
this will be a non-zero value, and nir should not need to lower shared
variables. If LowerShaderSharedVariables is not set, then nir will
need to lower the shared variables.
Signed-off-by: Jordan Justen
---
src/compiler/nir/glsl
Signed-off-by: Jordan Justen
---
src/compiler/nir/nir.c | 1 +
src/compiler/nir/nir.h | 2 +-
src/compiler/nir/nir_clone.c| 1 +
src/compiler/nir/nir_lower_io.c | 35 ---
src/compiler/nir/nir_print.c| 1 +
5 files changed, 32 insertion
Signed-off-by: Jordan Justen
---
src/compiler/nir/nir_lower_io.c | 86 -
1 file changed, 84 insertions(+), 2 deletions(-)
diff --git a/src/compiler/nir/nir_lower_io.c b/src/compiler/nir/nir_lower_io.c
index f844947..a869eb2 100644
--- a/src/compiler/nir/ni
Signed-off-by: Jordan Justen
---
src/compiler/nir/nir_print.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compiler/nir/nir_print.c b/src/compiler/nir/nir_print.c
index bdfbd26..231a4f5 100644
--- a/src/compiler/nir/nir_print.c
+++ b/src/compiler/nir/nir_print.c
@@ -312
On Mon, 2016-03-14 at 11:15 -0700, Mark Janes wrote:
> Iago Toral writes:
>
> > On Wed, 2016-03-09 at 09:54 +0200, Pohjolainen, Topi wrote:
> >> On Mon, Mar 07, 2016 at 10:48:49AM +0100, Samuel Iglesias Gons?lvez wrote:
> >> > Hello,
> >> >
> >> > There is only one patch from this series that ha
From: Roland Scheidegger
Some rasterization code relies (for sse) on the first and third planes
(but not the second for now) being 128bit aligned, and we didn't get that
on 32bit - I mistakenly thought the 64bit number in the struct would get
the thing aligned to 64bit even on 32bit archs.
Stepha
On Mon, Mar 14, 2016 at 9:13 PM, Kenneth Graunke
wrote:
> On Monday, March 14, 2016 5:23:44 PM PDT Jason Ekstrand wrote:
> > On Sun, Mar 13, 2016 at 6:08 PM, Kenneth Graunke
> > wrote:
> >
> > > We want to use interface_type, not vtn_var->type. They're normally
> > > equivalent, but for geometr
On Monday, March 14, 2016 5:25:58 PM PDT Matt Turner wrote:
> On Mon, Mar 14, 2016 at 5:22 PM, Matt Turner wrote:
> > On Mon, Mar 14, 2016 at 5:10 PM, Francisco Jerez
wrote:
> >> Matt Turner writes:
> >>
> >>> Missing this causes an assertion failure in the scheduler with the next
> >>> patch.
On Monday, March 14, 2016 5:23:44 PM PDT Jason Ekstrand wrote:
> On Sun, Mar 13, 2016 at 6:08 PM, Kenneth Graunke
> wrote:
>
> > We want to use interface_type, not vtn_var->type. They're normally
> > equivalent, but for geometry/tessellation per-vertex interface arrays,
> > we need to unwrap a l
Am 15.03.2016 um 02:37 schrieb Stéphane Marchesin:
> On Mon, Feb 1, 2016 at 8:14 AM, Brian Paul wrote:
>> On 01/31/2016 06:00 PM, srol...@vmware.com wrote:
>>>
>>> From: Roland Scheidegger
>>>
>>> When we switched to 64bit rasterization, we could no longer use straight
>>> aligned loads for loadi
https://bugs.freedesktop.org/show_bug.cgi?id=94522
--- Comment #6 from Stephane Marchesin ---
It is an alignment problem in the code. I fixed it with:
https://chromium-review.googlesource.com/#/c/332681/2/media-libs/mesa/files/10.5-lp_rast-Remove-alignment-constraints.patch
Feel free to try loc
On 15.03.2016 01:04, Daniel Stone wrote:
> On 9 March 2016 at 02:57, Michel Dänzer wrote:
>> On 08.03.2016 20:36, Daniel Stone wrote:
>>> Taking the approach I suggested would allow us to solve multi-GPU
>>> with the same approach, whereas with the wrapper driver ... who
>>> volunteers to write th
"In progress" would seem to imply someone is working on it, which, AFAIK,
is not the case.
On Mar 14, 2016 7:35 PM, "Romain Failliot"
wrote:
> This fixes some exceptions I have to deal with in mesamatrix.net.
> The extensions GL_ARB_texture_buffer_object had a comment between "DONE"
> and the bra
For older extensions, there is an explanation first and the extension
name in brackets, like that:
Clamping controls (GL_ARB_color_buffer_float)
I inverted that so we have the extension first and then the explanation
in brackets, like that:
GL_ARB_color_buffer_float (Clamping controls)
It
This fixes some exceptions I have to deal with in mesamatrix.net.
The extensions GL_ARB_texture_buffer_object had a comment between "DONE"
and the brackets.
And the extension GL_KHR_robustness (in GL 4.5 and GLES 3.1) was using
"90% done" instead of "in progress". The "90% done" is still here
thoug
The "Status" column was misaligned in some GL sections.
This is a lot of diffs, but it's only spaces in the end.
---
docs/GL3.txt | 278 +--
1 file changed, 139 insertions(+), 139 deletions(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index 1
Added a small guide on how to read and edit GL3.txt.
I think this would help as much the devs as the users reading this file.
---
docs/GL3.txt | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index ee7faca..1ed5c1a 100644
--
Hi!
With the recent commits, I'm having some trouble parsing the GL3.txt
text file for mesamatrix.net.
With these set of 4 patches, I'm proposing to rationalize this file a
little bit. Rest assure, the content is still exactly the same.
Cheers!
Romain Failliot (4):
docs: howto to read and edi
https://bugs.freedesktop.org/show_bug.cgi?id=94549
Bug ID: 94549
Summary: [swrast] piglit glsl-arb-fragment-coord-conventions
regression
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=94522
--- Comment #5 from comicfans44 ---
> This is with Weston's DRM-backend, right?
I think so . I'm using GMA500 driver and didn't launch X11, just run weston
from terminal.
> When does this happen btw.?
>
> Is it on Weston startup, or later, or
On Mon, Feb 1, 2016 at 8:14 AM, Brian Paul wrote:
> On 01/31/2016 06:00 PM, srol...@vmware.com wrote:
>>
>> From: Roland Scheidegger
>>
>> When we switched to 64bit rasterization, we could no longer use straight
>> aligned loads for loading the plane data. However, what the code actually
>> does
Thanks for the explanations, I'll resend these patch the right way.
2016-03-14 10:01 GMT-04:00 Nicolai Hähnle :
> Hi Romain,
>
> On 13.03.2016 16:50, Romain Failliot wrote:
>>
>> Hi!
>>
>> With the recent commits, I'm having some trouble parsing the GL3.txt
>> text file for mesamatrix.net.
>>
>> W
On 14.03.2016 16:23, Marek Olšák wrote:
Reviewed-by: Marek Olšák
Thanks.
Do we need to fix GL_SRGB8_ALPHA8 as well?
Not sure about ARB_texture_view. For ARB_shader_image_load_store, the
spec has a table with an exhaustive list of supported formats, and none
of them are SRGB.
Do we nee
Missing this causes an assertion failure in the scheduler with the next
patch.
---
src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 1 -
src/mesa/drivers/dri/i965/brw_vec4_tcs.cpp | 4 +++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_ge
On Mon, Mar 14, 2016 at 5:35 PM, Francisco Jerez wrote:
> Matt Turner writes:
>
>> On Mon, Mar 14, 2016 at 5:10 PM, Francisco Jerez
>> wrote:
>>> Matt Turner writes:
>>>
Missing this causes an assertion failure in the scheduler with the next
patch.
---
src/mesa/drivers/dri
Matt Turner writes:
> On Mon, Mar 14, 2016 at 5:10 PM, Francisco Jerez
> wrote:
>> Matt Turner writes:
>>
>>> Missing this causes an assertion failure in the scheduler with the next
>>> patch.
>>> ---
>>> src/mesa/drivers/dri/i965/brw_ir_vec4.h | 3 ++-
>>> 1 file changed, 2 insertions(+), 1
I had a few comments, but by-and-large it looks fine. If you think you
need to do a respin, that's fine. Otherwise, with the comments addressed,
Reviewed-by: Jason Ekstrand
On Mon, Mar 7, 2016 at 12:45 AM, Samuel Iglesias Gonsálvez <
sigles...@igalia.com> wrote:
> Hello,
>
> Iago and I are wo
On Mon, Mar 7, 2016 at 12:46 AM, Samuel Iglesias Gonsálvez <
sigles...@igalia.com> wrote:
> From: Connor Abbott
>
> When we replace an expresion we have to compute bitsize information for the
> replacement. We do this in two passes to validate that bitsize information
> is consistent and correct:
On Mon, Mar 14, 2016 at 5:22 PM, Matt Turner wrote:
> On Mon, Mar 14, 2016 at 5:10 PM, Francisco Jerez
> wrote:
>> Matt Turner writes:
>>
>>> Missing this causes an assertion failure in the scheduler with the next
>>> patch.
>>> ---
>>> src/mesa/drivers/dri/i965/brw_ir_vec4.h | 3 ++-
>>> 1 fi
On Sun, Mar 13, 2016 at 6:08 PM, Kenneth Graunke
wrote:
> We want to use interface_type, not vtn_var->type. They're normally
> equivalent, but for geometry/tessellation per-vertex interface arrays,
> we need to unwrap a level.
>
> Otherwise, we tried to iterate a structure members but instead us
On Mon, Mar 14, 2016 at 5:10 PM, Francisco Jerez wrote:
> Matt Turner writes:
>
>> Missing this causes an assertion failure in the scheduler with the next
>> patch.
>> ---
>> src/mesa/drivers/dri/i965/brw_ir_vec4.h | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/src
Matt Turner writes:
> Missing this causes an assertion failure in the scheduler with the next
> patch.
> ---
> src/mesa/drivers/dri/i965/brw_ir_vec4.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_ir_vec4.h
> b/src/mesa/drivers/dri/i965
On Mon, Mar 14, 2016 at 7:48 PM, Jason Ekstrand wrote:
>
>
> On Mon, Mar 7, 2016 at 12:46 AM, Samuel Iglesias Gonsálvez
> wrote:
>>
>> From: Connor Abbott
>>
>> v2: Use the bit-size information from the opcode information if defined
>> (Iago)
>>
>> Signed-off-by: Iago Toral Quiroga
>>
>> FIXME:
Matt Turner writes:
> I think when this code was written, basic blocks were always ended by a
> control flow instruction or an end-of-thread message. That's no longer
> the case, and removing this restriction actually helps things:
>
>instructions in affected programs: 7267 -> 7244 (-0.32%)
>
Matt Turner writes:
> ---
> src/mesa/drivers/dri/i965/brw_shader.cpp | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
> b/src/mesa/drivers/dri/i965/brw_shader.cpp
> index dfe6afc..d007ed0 100644
> --- a/src/mesa/drivers/dri/i965/brw_shader.cp
On Mon, Mar 7, 2016 at 12:46 AM, Samuel Iglesias Gonsálvez <
sigles...@igalia.com> wrote:
> From: Connor Abbott
>
> v2: Use the bit-size information from the opcode information if defined
> (Iago)
>
> Signed-off-by: Iago Toral Quiroga
>
> FIXME: This should be squashed into the previous commit s
Removed bound_to_context. We now pick up the context from the screen
instead of the resource itself. The resource could be out-of-date
and point to a pipe that is already freed.
Fixes manywin mesa xdemo.
---
src/gallium/drivers/swr/swr_context.cpp | 16 +++-
src/gallium/drivers/swr/
On Monday, March 14, 2016 3:00:06 PM PDT Kenneth Graunke wrote:
> Thanks to James Legg for finding this!
>
> From the ARB_tessellation_shader spec:
> "The number of isolines generated is derived from the first outer
> tessellation level; the number of segments in each isoline is
> derived from t
Thanks to James Legg for finding this!
From the ARB_tessellation_shader spec:
"The number of isolines generated is derived from the first outer
tessellation level; the number of segments in each isoline is
derived from the second outer tessellation level."
According to the PRM, "TF.LineDensity
Matt Turner writes:
> On Sun, Mar 13, 2016 at 8:47 PM, Francisco Jerez
> wrote:
>> This could be improved somewhat with additional validation of the
>> calculated live in/out sets and by checking that the calculated live
>> intervals are minimal (which isn't strictly necessary to guarantee the
Build mesa 636 completed
Commit 4d02e91e49 by Hans de Goede on 3/14/2016 2:01 PM:
clover: Fix pipe_grid_info.indirect not being initialized.\n\nAfter pipe_grid_info.indirect was introduced, clover was not modified\nto set it causing it to pass uninitialized mem
Reviewed-by: Marek Olšák
Do we need to fix GL_SRGB8_ALPHA8 as well?
Do we need to update st_extensions.c to check that all formats with
the RGBA order are supported before enabling ARB_texture_view or
ARB_shader_image_load_store?
Marek
On Mon, Mar 14, 2016 at 9:42 PM, Nicolai Hähnle wrote:
>
Build mesa 635 failed
Commit af06190760 by Sarah Sharp on 10/29/2015 11:11 PM:
mesa: docs: Intel i965 hardware limits.\n\nThis should help the next person working on hardware enabling figure out\nwhere in the Intel PRMs to find the magic platform hardware value
I waited a little less than a week for review, but got no responses, so
I've pushed these two trivial docs patches to master.
Sarah Sharp
On Tue, Mar 08, 2016 at 11:42:44AM -0800, Sarah Sharp wrote:
> v2:
> - use \name doxygen format instead of @defgroup, which creates
>a separate module - a
On 03/14/2016 09:49 PM, Francisco Jerez wrote:
Samuel Pitoiset writes:
On 03/14/2016 02:29 PM, Samuel Pitoiset wrote:
On 03/14/2016 02:26 PM, Hans de Goede wrote:
Hi,
On 14-03-16 14:01, Samuel Pitoiset wrote:
On 03/14/2016 01:50 PM, Hans de Goede wrote:
After pipe_grid_info.indirect
On Mon, Mar 7, 2016 at 12:46 AM, Samuel Iglesias Gonsálvez <
sigles...@igalia.com> wrote:
> From: Connor Abbott
>
> ---
> src/compiler/nir/nir.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index d493186..d2fd23d 100644
> --- a/sr
On 03/14/2016 08:50 PM, Hans de Goede wrote:
Hi,
On 14-03-16 16:41, Samuel Pitoiset wrote:
On 03/14/2016 04:28 PM, Hans de Goede wrote:
Hi,
On 14-03-16 16:05, Ilia Mirkin wrote:
There's a less hacky and more hacky way forward. The more hacky
solution is
to set file index to -1 or somethi
Samuel Pitoiset writes:
> On 03/14/2016 02:29 PM, Samuel Pitoiset wrote:
>>
>>
>> On 03/14/2016 02:26 PM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 14-03-16 14:01, Samuel Pitoiset wrote:
On 03/14/2016 01:50 PM, Hans de Goede wrote:
> After pipe_grid_info.indirect was introduced,
From: Nicolai Hähnle
The bitcasting which is possible with shader images (and texture views?)
requires that when the user specifies a sized internal format for a
texture, we really allocate that format. To this end:
(1) find_exact_format should ignore sized internal formats and
(2) some of the
On Mon, Mar 7, 2016 at 12:46 AM, Samuel Iglesias Gonsálvez <
sigles...@igalia.com> wrote:
> From: Connor Abbott
>
> ---
> src/compiler/nir/nir.h | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index 39aad02..c7e4dcc 100644
> ---
On Mon, Mar 7, 2016 at 12:46 AM, Samuel Iglesias Gonsálvez <
sigles...@igalia.com> wrote:
> From: Connor Abbott
>
> ---
> src/compiler/nir/nir.h | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index d2fd23d..39aad02 100644
> ---
Hi,
On 14-03-16 16:41, Samuel Pitoiset wrote:
On 03/14/2016 04:28 PM, Hans de Goede wrote:
Hi,
On 14-03-16 16:05, Ilia Mirkin wrote:
There's a less hacky and more hacky way forward. The more hacky
solution is
to set file index to -1 or something and then not do the lowering when
you
see tha
On 14/03/16 18:44, Anuj Phogat wrote:
> Cc: Alejandro Piñeiro
> Signed-off-by: Anuj Phogat
> ---
> src/mesa/swrast/s_texture.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/swrast/s_texture.c b/src/mesa/swrast/s_texture.c
> index 9ccd0e3..25918e3 100644
> --
On 14/03/16 19:59, Kyle Brenneman wrote:
On 03/14/2016 11:43 AM, Martin Peres wrote:
On 14/03/16 19:16, Kyle Brenneman wrote:
On 03/11/2016 05:25 PM, Martin Peres wrote:
On 10/03/16 20:07, Adam Jackson wrote:
On Thu, 2016-03-10 at 10:53 -0700, Kyle Brenneman wrote:
On 03/10/2016 10:47 AM, M
For the series:
Reviewed-by: Marek Olšák
Marek
On Sun, Mar 13, 2016 at 3:29 PM, Nicolai Hähnle wrote:
> Hi,
>
> this is probably my last batch of hardware-independent patches that need
> to be pushed before the series that finally adds ARB_shader_image_load_store
> for radeonsi.
>
> Patches 1
On Mon, Mar 14, 2016 at 2:10 PM, Jason Ekstrand wrote:
>
>
> On Mon, Mar 7, 2016 at 12:46 AM, Samuel Iglesias Gonsálvez
> wrote:
>>
>> From: Connor Abbott
>>
>> Some opcodes need explicit bitsizes, and sometimes we need to use the
>> double version when constant folding.
>>
>> v2: fix output typ
Iago Toral writes:
> On Wed, 2016-03-09 at 09:54 +0200, Pohjolainen, Topi wrote:
>> On Mon, Mar 07, 2016 at 10:48:49AM +0100, Samuel Iglesias Gons?lvez wrote:
>> > Hello,
>> >
>> > There is only one patch from this series that has been reviewed (patch
>> > 1).
>> >
>> > Our plans is to start se
On Mon, Mar 7, 2016 at 12:46 AM, Samuel Iglesias Gonsálvez <
sigles...@igalia.com> wrote:
> From: Connor Abbott
>
> Some opcodes need explicit bitsizes, and sometimes we need to use the
> double version when constant folding.
>
> v2: fix output type for u2f (Iago)
>
> v3: do not change vecN opcod
On 03/14/2016 11:43 AM, Martin Peres wrote:
On 14/03/16 19:16, Kyle Brenneman wrote:
On 03/11/2016 05:25 PM, Martin Peres wrote:
On 10/03/16 20:07, Adam Jackson wrote:
On Thu, 2016-03-10 at 10:53 -0700, Kyle Brenneman wrote:
On 03/10/2016 10:47 AM, Martin Peres wrote:
That could be a hack
On 14/03/16 19:16, Kyle Brenneman wrote:
On 03/11/2016 05:25 PM, Martin Peres wrote:
On 10/03/16 20:07, Adam Jackson wrote:
On Thu, 2016-03-10 at 10:53 -0700, Kyle Brenneman wrote:
On 03/10/2016 10:47 AM, Martin Peres wrote:
That could be a hacky way of handling the case where multiple 3D
Cc: Alejandro Piñeiro
Signed-off-by: Anuj Phogat
---
src/mesa/swrast/s_texture.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/swrast/s_texture.c b/src/mesa/swrast/s_texture.c
index 9ccd0e3..25918e3 100644
--- a/src/mesa/swrast/s_texture.c
+++ b/src/mesa/swrast/s_t
https://bugs.freedesktop.org/show_bug.cgi?id=94522
--- Comment #4 from Roland Scheidegger ---
So, it crashed in the jit fragment shader code.
Could you tell what the fb size was (the values from scene->fb in
lp_rast_shade_tile, possibly the ones from the (first) color and zbuffer
themselves)? I w
On 03/11/2016 05:25 PM, Martin Peres wrote:
On 10/03/16 20:07, Adam Jackson wrote:
On Thu, 2016-03-10 at 10:53 -0700, Kyle Brenneman wrote:
On 03/10/2016 10:47 AM, Martin Peres wrote:
That could be a hacky way of handling the case where multiple 3D
drivers could be used to drive the same GP
On Sat, Mar 12, 2016 at 1:42 AM, Alejandro Piñeiro
wrote:
> On 12/03/16 00:16, Anuj Phogat wrote:
> > Signed-off-by: Anuj Phogat
>
> Any reason to not just move the slice assert at line 243 as part of the
> checks of check_map_teximage?
>
Didn't notice it. I'll take your suggestion and send out
https://bugs.freedesktop.org/show_bug.cgi?id=94522
Daniel Stone changed:
What|Removed |Added
Assignee|wayland-bugs@lists.freedesk |mesa-dev@lists.freedesktop.
Allow the sequence operator to be a constant expression in GLSL ES versions
prior
to GLSL ES 3.0
Fixes the following piglit test:
/all/spec/glsl-es-1.0/compiler/array-sized-by-sequence-in-parenthesis.vert
This mirrors the logic from process_initializer() which performs the
same check for cons
On Mon, 2016-03-14 at 10:19 +0800, Chih-Wei Huang wrote:
> 2016-03-11 11:50 GMT+08:00 Jan Vesely :
> >
> > On Fri, 2016-03-11 at 10:09 +0800, Chih-Wei Huang wrote:
> > >
> > > cc1: some warnings being treated as errors
> > >
> > >
> > > But I'm still not sure whether if it should be fixed on th
Hi,
On 9 March 2016 at 02:57, Michel Dänzer wrote:
> On 08.03.2016 20:36, Daniel Stone wrote:
>> Taking the approach I suggested would allow us to solve multi-GPU
>> with the same approach, whereas with the wrapper driver ... who
>> volunteers to write the Radeon+Intel combination driver?
>
> Why
Hey Emil,
On 8 March 2016 at 17:04, Emil Velikov wrote:
> Summarising and stating some unsaid assumptions.
>
> Assumptions:
> - The proposed solution is a replacement of the wrapped drivers
> approach. No, it's meant to introduce an API mostly gears towards
> DRI_PRIME setups.
> - Wrapped drive
On 03/14/2016 04:28 PM, Hans de Goede wrote:
Hi,
On 14-03-16 16:05, Ilia Mirkin wrote:
There's a less hacky and more hacky way forward. The more hacky
solution is
to set file index to -1 or something and then not do the lowering when
you
see that.
The less hacky solution is the one you propo
Hi,
On 14-03-16 16:05, Ilia Mirkin wrote:
There's a less hacky and more hacky way forward. The more hacky solution is
to set file index to -1 or something and then not do the lowering when you
see that.
The less hacky solution is the one you proposed as #1 - introduce a new
file for "buffer" me
There's a less hacky and more hacky way forward. The more hacky solution is
to set file index to -1 or something and then not do the lowering when you
see that.
The less hacky solution is the one you proposed as #1 - introduce a new
file for "buffer" memory and lower it to the global file by addin
Thanks Hans!
Reviewed-by: Samuel Pitoiset
On 03/14/2016 03:01 PM, Hans de Goede wrote:
After pipe_grid_info.indirect was introduced, clover was not modified
to set it causing it to pass uninitialized memory for it to launch_grid.
This commit fixes this by zero-ing the entire pipe_grid_info st
Hi Romain,
On 13.03.2016 16:50, Romain Failliot wrote:
Hi!
With the recent commits, I'm having some trouble parsing the GL3.txt
text file for mesamatrix.net.
With these set of 4 patches, I'm proposing to rationalize a little bit
this file. The content is exactly the same.
(Note: I'm not really
After pipe_grid_info.indirect was introduced, clover was not modified
to set it causing it to pass uninitialized memory for it to launch_grid.
This commit fixes this by zero-ing the entire pipe_grid_info struct when
declaring it, to avoid similar problems popping-up in the future.
Cc: "11.2"
Sig
Messed up the subject prefix, sorry. Resending with proper prefix.
On 14-03-16 15:00, Hans de Goede wrote:
After pipe_grid_info.indirect was introduced, clover was not modified
to set it causing it to pass uninitialized memory for it to launch_grid.
This commit fixes this by zero-ing the entire
After pipe_grid_info.indirect was introduced, clover was not modified
to set it causing it to pass uninitialized memory for it to launch_grid.
This commit fixes this by zero-ing the entire pipe_grid_info struct when
declaring it, to avoid similar problems popping-up in the future.
Cc: "11.2"
Sig
On 03/14/2016 02:29 PM, Samuel Pitoiset wrote:
On 03/14/2016 02:26 PM, Hans de Goede wrote:
Hi,
On 14-03-16 14:01, Samuel Pitoiset wrote:
On 03/14/2016 01:50 PM, Hans de Goede wrote:
After pipe_grid_info.indirect was introduced, clover was not modified
to set it causing it to pass unini
On 03/14/2016 02:26 PM, Hans de Goede wrote:
Hi,
On 14-03-16 14:01, Samuel Pitoiset wrote:
On 03/14/2016 01:50 PM, Hans de Goede wrote:
After pipe_grid_info.indirect was introduced, clover was not modified
to set it causing it to pass uninitialized memory for it to launch_grid.
This commi
Hi,
On 14-03-16 14:01, Samuel Pitoiset wrote:
On 03/14/2016 01:50 PM, Hans de Goede wrote:
After pipe_grid_info.indirect was introduced, clover was not modified
to set it causing it to pass uninitialized memory for it to launch_grid.
This commit fixes this by zero-ing the entire pipe_grid_in
This little "hack" fixes the use of OpenCL global memory buffers with
nouveau, but clearly the #if 0 is not a solution as it breaks buffers
with GLSL.
The reason I'm posting this as an RFC patch is to discuss how to solve
this properly, 2 solutions come to mind:
1) Use separate nv50_ir::FILE_MEMO
On 03/14/2016 01:50 PM, Hans de Goede wrote:
After pipe_grid_info.indirect was introduced, clover was not modified
to set it causing it to pass uninitialized memory for it to launch_grid.
This commit fixes this by zero-ing the entire pipe_grid_info struct when
declaring it, to avoid similar pr
After pipe_grid_info.indirect was introduced, clover was not modified
to set it causing it to pass uninitialized memory for it to launch_grid.
This commit fixes this by zero-ing the entire pipe_grid_info struct when
declaring it, to avoid similar problems popping-up in the future.
Signed-off-by:
On Wed, 2016-03-09 at 09:54 +0200, Pohjolainen, Topi wrote:
> On Mon, Mar 07, 2016 at 10:48:49AM +0100, Samuel Iglesias Gons?lvez wrote:
> > Hello,
> >
> > There is only one patch from this series that has been reviewed (patch
> > 1).
> >
> > Our plans is to start sending patches for adding fp64
https://bugs.freedesktop.org/show_bug.cgi?id=94522
--- Comment #3 from Pekka Paalanen ---
When does this happen btw.?
Is it on Weston startup, or later, or perhaps when you try to run any
application using OpenGL under Weston?
--
You are receiving this mail because:
You are the QA Contact for
https://bugs.freedesktop.org/show_bug.cgi?id=94522
--- Comment #2 from Pekka Paalanen ---
This is with Weston's DRM-backend, right?
I'll just point out that this has nothing to do with Wayland. even if it was a
Weston bug which I doubt. Any application that runs on KMS and uses
kms_swrast_dri.so
91 matches
Mail list logo
