https://bugs.freedesktop.org/show_bug.cgi?id=92869
Bug ID: 92869
Summary: OpenGL ES 3.0 context creation failure
Product: Mesa
Version: 11.0
Hardware: All
OS: All
Status: NEW
Severity: normal
Pri
On 08.11.2015 22:44, Marek Olšák wrote:
From: Marek Olšák
Unaligned 8-bit and 16-bit clears are done in software.
I found this confusing at first. I think a better phrasing is something
along the lines of:
8-bit and 16-bit clears which are not aligned to dwords are done in
software.
Wit
Hi Leo,
Please, if you do not understand what was said earlier ask for
clarification rather than just ignoring it.
For example:
On 6 November 2015 at 18:43, Leo Liu wrote:
> This will allow the state trackers to use render nodes
> with screen creation
>
> v2 -dup fd for pipe loader
>
> Signed-o
Hi Leo,
I'm glad that you've caught the places where I was day dreaming but
again, please don't just ignore suggestions. If you believe there is
something wrong with them just say so (as you did with
debug_get_options).
On 6 November 2015 at 18:43, Leo Liu wrote:
> This will allow dec/enc/transc
On 06.11.2015 20:58, Marek Olšák wrote:
> On Wed, Nov 4, 2015 at 11:05 AM, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> Fixes GPUVM conflicts with non-4K page size.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92738
>>
>> v2: Replace sanitization of VM base address alignment
The series is
Reviewed-by: Nicolai Hähnle
On 08.11.2015 22:45, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/drivers/r600/evergreen_compute.c| 14 ++---
src/gallium/drivers/r600/evergreen_hw_context.c | 10 ++--
src/gallium/drivers/r600/evergreen_state.c | 66
On 08.11.2015 22:48, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_pipe_common.c | 22 +-
src/gallium/drivers/radeon/r600_pipe_common.h | 4
2 files changed, 5 insertions(+), 21 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_p
On 09.11.2015 10:43, Nicolai Hähnle wrote:
On 08.11.2015 22:48, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_pipe_common.c | 22
+-
src/gallium/drivers/radeon/r600_pipe_common.h | 4
2 files changed, 5 insertions(+), 21 deletions(-)
di
On 09.11.2015 07:00, Marek Olšák wrote:
> From: Marek Olšák
>
> I discovered that increasing the ESGS ring size fixes GS hangs on Tonga,
> so let's do it properly.
>
> There is now a separate init_config_gs_rings state that is not immutable,
> because GS rings are resized when needed.
>
> This
On 09.11.2015 07:00, Marek Olšák wrote:
> This fixes hangs on Tonga when the ESGS ring isn't large enough. It's also a
> requirement for this not-yet-committed patch:
>
>"radeonsi: link ES-GS just like LS-HS"
>
> which makes GS hangs easier to reproduce. The ring size equations are based
>
On 08.11.2015 22:48, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/drivers/r600/r600_hw_context.c| 2 +-
src/gallium/drivers/r600/r600_state_common.c | 2 +-
src/gallium/drivers/radeon/r600_pipe_common.h | 1 -
src/gallium/drivers/radeon/r600_query.c | 1 -
src/gallium/d
The series is
Reviewed-by: Nicolai Hähnle
On 08.11.2015 22:48, Marek Olšák wrote:
From: Marek Olšák
and ..._cond -> ..._invert
---
src/gallium/drivers/r600/r600_hw_context.c| 2 +-
src/gallium/drivers/r600/r600_state_common.c | 2 +-
src/gallium/drivers/radeon/r600_pipe_common.h |
On 08.11.2015 23:00, Marek Olšák wrote:
From: Marek Olšák
I discovered that increasing the ESGS ring size fixes GS hangs on Tonga,
so let's do it properly.
There is now a separate init_config_gs_rings state that is not immutable,
because GS rings are resized when needed.
This also saves some
https://bugs.freedesktop.org/show_bug.cgi?id=92278
--- Comment #9 from komin...@gmail.com ---
(In reply to Sven Arvidsson from comment #5)
> The patch works fine here, awesome work! Fantastic to have it fixed so
> quickly!
>
> The developer of the game is Gaijin Entertainment, http://gaijinent.co
https://bugs.freedesktop.org/show_bug.cgi?id=92869
Jose Fonseca changed:
What|Removed |Added
CC||chad.vers...@intel.com,
https://bugs.freedesktop.org/show_bug.cgi?id=92278
--- Comment #10 from komin...@gmail.com ---
worked with
MESA_GL_VERSION_OVERRIDE=4.1COMPAT ~/.steam/steam/steamapps/common/War\
Thunder/launcher
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for
On 11/08/2015 07:04 AM, Kenneth Graunke wrote:
> This allows arbitrary non-constant indices on GS input arrays,
> both for the vertex index, and any array offsets beyond that.
>
> All indirects are handled via the pull model. We could potentially
> handle indirect addressing of pushed data as w
Hi,
Currently, NIR defines vecN operations as unsigned (integer). The fp64
patches from Connor change this to float (I guess because we need to
know the case where we are packing vectors of 64-bit floats). However,
this makes it so that nir_lower_source_to_mods turns this:
vec1 ssa_2 = f
On 8 November 2015 at 21:45, Marek Olšák wrote:
> From: Marek Olšák
>
> otherwise the SX or CB blocks can go bananas
> ---
Should we get this into stable as well, considering Alex requested
that we have Stoney support there ? It seems that other fixes
d57ede92b78 are missing the tag.
Can we get
Reviewed-by: Samuel Iglesias Gonsálvez
On 08/11/15 23:34, Timothy Arceri wrote:
> From: Timothy Arceri
>
> Qualifiers on member variables are redundent all we need to do
> if check if it matches the stream associated with the block and
> throw an error if its not.
>
> Cc: Samuel Iglesias Gonsa
On Sun, Nov 8, 2015 at 7:58 PM, Timothy Arceri wrote:
> On Sun, 2015-11-08 at 15:12 -0500, Rob Clark wrote:
>> From: Rob Clark
>>
>> With TGSI, the ir_variable::data.location gets fixed up to be a stage
>> local location (rather than program global). In this case we need to
>> skip the UniformSt
The current code is busted in a number of ways.
- initially checks for omx_display (rather than omx_screen), which may
or may not be around.
- blindly feeds the empty env variable string to loader_open_device()
- reads the env variable every time get_screen is called
- the latter manifests int
2015-11-09 12:55 GMT+01:00 Iago Toral :
> Hi,
>
> Currently, NIR defines vecN operations as unsigned (integer). The fp64
> patches from Connor change this to float (I guess because we need to
> know the case where we are packing vectors of 64-bit floats). However,
> this makes it so that nir_lower
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/xvmc/context.c | 10 +-
src/gallium/state_trackers/xvmc/surface.c | 13 ++---
2 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/src/gallium/state_trackers/xvmc/context.c
b/src/gallium/state_trackers/xvmc/co
Hi all,
Inspired by the resent interest in alternative vl winsys, I've decided
to rework the winsys into a traditional gallium fashion.
Namely: add the destroy() and other functions into struct vl_screen.
This will allow users (state-trackers) to call the
vl_foo_screen_create() entry point and
... just like every other place in gallium.
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/vl/vl_winsys_drm.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_winsys_drm.c
b/src/gallium/auxiliary/vl/vl_winsys_drm.c
index 2e
Drop the temporary variable and fold the two conditional.
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/va/context.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/src/gallium/state_trackers/va/context.c
b/src/gallium/state_trackers/va/context.c
ind
Rewrap long(ish) lines, add space between struct foo and *.
Trivial or bikeshedding you decide.
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/vl/vl_winsys.h | 2 +-
src/gallium/auxiliary/vl/vl_winsys_dri.c | 54 +++-
2 files changed, 34 insertions(+), 22
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/omx/entrypoint.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/src/gallium/state_trackers/omx/entrypoint.c
b/src/gallium/state_trackers/omx/entrypoint.c
index d369cec..883a2a1 100644
--- a/src/gallium/st
Signed-off-by: Emil Velikov
---
This commit might cause some build warnings, all of which are handled
with the next commit(s).
-Emil
src/gallium/auxiliary/vl/vl_winsys.h | 4 ++--
src/gallium/auxiliary/vl/vl_winsys_dri.c | 19 +--
2 files changed, 15 insertions(+), 8 dele
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/vl/vl_winsys_drm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/auxiliary/vl/vl_winsys_drm.c
b/src/gallium/auxiliary/vl/vl_winsys_drm.c
index 1167fcf..2ebf20c 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_drm.c
+++
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/vdpau/device.c | 4 ++--
src/gallium/state_trackers/vdpau/presentation.c | 18 +-
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/src/gallium/state_trackers/vdpau/device.c
b/src/gallium/state_track
As of last commit everyone is using the vl_screen dispatch, thus we can
hide this function from the headers and make it static.
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/vl/vl_winsys.h | 3 ---
src/gallium/auxiliary/vl/vl_winsys_drm.c | 7 +--
2 files changed, 5 insertions(+)
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/va/context.c | 10 ++
src/gallium/state_trackers/va/picture.c | 2 +-
src/gallium/state_trackers/va/surface.c | 13 ++---
3 files changed, 9 insertions(+), 16 deletions(-)
diff --git a/src/gallium/state_trackers/va/conte
As mentioned previously, it will allow us to use different vl backend in
a generic way from either video state-tracker.
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/vl/vl_winsys.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/src/gallium/auxiliary/vl/vl_winsys.h
In a preparation of having proper multiplatform/backend handling in VL.
With follow up commits we'll introduce a dispatch within vl_screen
similar to the one in pipe_screen. This way any VL state-tracker can
overate seemlessly, considering the backend/platform is properly setup.
Signed-off-by: Em
Analogous to previous commit. While we're here prefix all functions
identically -> vl_dri2_foo
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/vl/vl_winsys.h | 17 ---
src/gallium/auxiliary/vl/vl_winsys_dri.c | 37 +---
2 files changed, 20 insert
On 30 October 2015 at 17:57, Emil Velikov wrote:
> On 19 October 2015 at 18:41, Emil Velikov wrote:
>> On 19 October 2015 at 17:07, Brian Paul wrote:
>
>>>
>>> I'm not too familiar with this code or these changes but I'm wondering how
>>> much of chance there is of this breaking any driver/targe
On Mon, Nov 9, 2015 at 8:30 AM, Emil Velikov wrote:
> On 30 October 2015 at 17:57, Emil Velikov wrote:
>> On 19 October 2015 at 18:41, Emil Velikov wrote:
>>> On 19 October 2015 at 17:07, Brian Paul wrote:
>>
I'm not too familiar with this code or these changes but I'm wondering how
>
A few points to note here:
(a) We're obviously faking MSAA support here -- not actually
supporting the 4x MSAA that GL 3.0 requires (although the HW does
support that)
(b) We're only exposing 4 MRT's -- that is a HW limit. I guess one
could do something with a second per-tile runthrough for the
ad
Am 09.11.2015 um 04:44 schrieb Dave Airlie:
> So it appears my patch to enable front buffer access on soft/llvmpipe
> causes some piglit regressions. However these are due to piglit having
> undefined behaviour where it doesn't create a window but has tests
> requiring a front buffer. The new code
Am 09.11.2015 um 05:19 schrieb Dave Airlie:
> From: Dave Airlie
>
> There might be a reason we do this inside the thread, but I'm not aware of it
> yet, move stuff around and see if this jogs anyone's memory.
>
> Doing this outside the thread at least with front buffer rendering avoids
> problem
>-Original Message-
>From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
>Sent: Monday, November 09, 2015 8:17 AM
>To: mesa-dev@lists.freedesktop.org
>Cc: emil.l.veli...@gmail.com; Liu, Leo
>Subject: [PATCH] st/omx: straighten get/put_screen
>
>The current code is busted in a number of way
On Mon, Nov 9, 2015 at 6:55 AM, Iago Toral wrote:
> Hi,
>
> Currently, NIR defines vecN operations as unsigned (integer). The fp64
> patches from Connor change this to float (I guess because we need to
> know the case where we are packing vectors of 64-bit floats). However,
> this makes it so that
On Nov 9, 2015 7:24 AM, "Connor Abbott" wrote:
>
> On Mon, Nov 9, 2015 at 6:55 AM, Iago Toral wrote:
> > Hi,
> >
> > Currently, NIR defines vecN operations as unsigned (integer). The fp64
> > patches from Connor change this to float (I guess because we need to
> > know the case where we are packi
On Wed, 2015-11-04 at 15:33 -0800, Kristian Høgsberg Kristensen wrote:
> All GLSL IR consumers run this lowering pass so we can move it to the
> linker. This moves the pass up quite a bit, but that's the point: it
> needs to run before we throw away information about per-component vector
> access.
Reviewed-by: Iago Toral Quiroga
On Wed, 2015-11-04 at 15:33 -0800, Kristian Høgsberg Kristensen wrote:
> We always pass in shader->ir and we already pass in the shader, so just
> drop the exec_list. Most passes either take just a exec_list or a
> shader, so this seems more consistent.
>
> Signed
On Mon, Nov 9, 2015 at 10:41 AM, Jason Ekstrand wrote:
>
> On Nov 9, 2015 7:24 AM, "Connor Abbott" wrote:
>>
>> On Mon, Nov 9, 2015 at 6:55 AM, Iago Toral wrote:
>> > Hi,
>> >
>> > Currently, NIR defines vecN operations as unsigned (integer). The fp64
>> > patches from Connor change this to floa
On 11/07/2015 09:05 PM, Jimmy Berry wrote:
- env GALLIUM_HUD_VISIBLE: control default visibility
- env GALLIUM_HUD_SIGNAL_TOGGLE: toggle visibility via signal
---
docs/envvars.html | 6 ++
src/gallium/auxiliary/hud/hud_context.c | 28
2
Given the fact that we have multiple possible uses for such an opcode,
I've been wondering if it wouldn't be better to simply have a
SHADER_OPCODE_INDIRECT_MOV opcode that works on pretty much any
register type. Given that they all get lowered away to HW_REG before
the end, the emit code wouldn't
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #52 from pavi...@yahoo.fr ---
I don't know if you are aware but there is a similar bug in chromium that as
been fixed.
https://code.google.com/p/chromium/issues/detail?id=442111
--
You are receiving this mail because:
You are the QA
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #53 from James Jones ---
I'll be out of the office for the next 2-3 weeks.
For Vulkan issues, talk to Damien Leone (dle...@nvidia.com)
For EGL issues, talk to Daniel Kartch (dkar...@nvidia.com)
-
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #54 from Furkan ---
Quoted from the Chromium bug report page:
"I disabled use_virtualized_gl_contexts on non-nvidia drivers in the latest
build of chromium"
I don't know what that does, but it looks like a workaround.
--
You are r
On Sun, Nov 8, 2015 at 8:53 PM, Ilia Mirkin wrote:
> It seems a bit odd to expect a debug message to contain a newline --
> what if you wanted to include something *after* the message, for
> example. It makes more sense for the code actually printing to have the
> newline rather than the string be
On 9 November 2015 at 15:22, Liu, Leo wrote:
>>-Original Message-
>>From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
>>Sent: Monday, November 09, 2015 8:17 AM
>>To: mesa-dev@lists.freedesktop.org
>>Cc: emil.l.veli...@gmail.com; Liu, Leo
>>Subject: [PATCH] st/omx: straighten get/put_scr
On Sun, Nov 8, 2015 at 8:53 PM, Ilia Mirkin wrote:
> st/mesa only prints messages in a debug context. Without always enabling
> the message generation, I don't see a way to hook into the glEnable() to
> turn it on/off.
> ---
> run.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/run.c b
I think Ken has some hacks in Mesa to dump shaders, so we don't use
this script very much any more. Feel free to commit this in any case.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Feel free to commit!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Fri, Oct 30, 2015 at 10:49 AM, Connor Abbott wrote:
> Ping. I just pushed the corresponding mesa patch to master yesterday,
> so I'd like to get this landed in shader-db soon.
Acked-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedeskto
Signed-off-by: Ilia Mirkin
---
src/gallium/docs/source/context.rst | 4
src/gallium/docs/source/screen.rst | 2 ++
src/gallium/drivers/freedreno/freedreno_screen.c | 1 +
src/gallium/drivers/i915/i915_screen.c | 1 +
src/gallium/drivers/ilo/ilo_screen
This is basically a resend of a series I wrote over a year ago. I
don't remember what we hated about it last time, but I'm tempted not
to look. This seems pretty reasonably to me now.
A refactoring opportunity exists to remove ->clear_render_target and
->clear_depth_stencil, but... that can be don
Signed-off-by: Ilia Mirkin
---
src/mesa/state_tracker/st_cb_texture.c | 29 +
src/mesa/state_tracker/st_extensions.c | 1 +
2 files changed, 30 insertions(+)
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index d4c916e..
Signed-off-by: Ilia Mirkin
---
docs/GL3.txt| 2 +-
docs/relnotes/11.1.0.html | 1 +
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 +-
src/gallium/drivers/nouveau/nvc0/nvc0_surface.c | 82 +
4 files changed,
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #56 from Antoine Labour ---
(In reply to Furkan from comment #54)
> Quoted from the Chromium bug report page:
>
> "I disabled use_virtualized_gl_contexts on non-nvidia drivers in the latest
> build of chromium"
>
> I don't know what
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #55 from Antoine Labour ---
(In reply to paviluf from comment #52)
> I don't know if you are aware but there is a similar bug in chromium that as
> been fixed.
> https://code.google.com/p/chromium/issues/detail?id=442111
Yeah, that b
I used this script in conjunction with ST_DUMP_SHADERS. What other way is there?
On Mon, Nov 9, 2015 at 1:36 PM, Matt Turner wrote:
> I think Ken has some hacks in Mesa to dump shaders, so we don't use
> this script very much any more. Feel free to commit this in any case.
___
>-Original Message-
>From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
>Sent: Monday, November 09, 2015 1:34 PM
>To: Liu, Leo
>Cc: mesa-dev@lists.freedesktop.org
>Subject: Re: [PATCH] st/omx: straighten get/put_screen
>
>On 9 November 2015 at 15:22, Liu, Leo wrote:
>>>-Original Me
On Mon, Nov 9, 2015 at 1:35 PM, Matt Turner wrote:
> On Sun, Nov 8, 2015 at 8:53 PM, Ilia Mirkin wrote:
>> st/mesa only prints messages in a debug context. Without always enabling
>> the message generation, I don't see a way to hook into the glEnable() to
>> turn it on/off.
>> ---
>> run.c | 1 +
On Mon, Nov 9, 2015 at 10:46 AM, Ilia Mirkin wrote:
> I used this script in conjunction with ST_DUMP_SHADERS. What other way is
> there?
Some local hack and we should probably finish and upstream.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.or
On Mon, Nov 9, 2015 at 10:46 AM, Ilia Mirkin wrote:
> On Mon, Nov 9, 2015 at 1:35 PM, Matt Turner wrote:
>> On Sun, Nov 8, 2015 at 8:53 PM, Ilia Mirkin wrote:
>>> st/mesa only prints messages in a debug context. Without always enabling
>>> the message generation, I don't see a way to hook into t
On Mon, Nov 9, 2015 at 1:56 PM, Matt Turner wrote:
> On Mon, Nov 9, 2015 at 10:46 AM, Ilia Mirkin wrote:
>> On Mon, Nov 9, 2015 at 1:35 PM, Matt Turner wrote:
>>> On Sun, Nov 8, 2015 at 8:53 PM, Ilia Mirkin wrote:
st/mesa only prints messages in a debug context. Without always enabling
>>>
On Tue 03 Nov 2015, Ben Widawsky wrote:
> On Fri, Oct 16, 2015 at 04:05:22PM -0700, Chad Versace wrote:
> > On Tue 13 Oct 2015, Ben Widawsky wrote:
> > > Initially I had this planned as a patch to be squashed in to the enabling
> > > patch
> > > because there is no point enabling fast clears witho
On Tue 03 Nov 2015, Ben Widawsky wrote:
> On Fri, Oct 16, 2015 at 04:10:02PM -0700, Chad Versace wrote:
> > But this patch doesn't enable fast clears! The reverts in pathches 6 and
> > 7 need to be folded into this patch, otherwise the patch does not do
> > what it claims.
> >
> > Also, you can't
On Saturday, November 07, 2015 08:40:51 AM Ben Widawsky wrote:
> On Fri, Nov 06, 2015 at 07:29:18PM -0800, Kenneth Graunke wrote:
> > On Friday, November 06, 2015 06:12:27 PM Ben Widawsky wrote:
> > > The comment in the code details the restriction. Thanks to Ken for having
> > > a very
> > > help
On 11/09/2015 07:40 PM, Ilia Mirkin wrote:
Signed-off-by: Ilia Mirkin
---
docs/GL3.txt| 2 +-
docs/relnotes/11.1.0.html | 1 +
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 +-
src/gallium/drivers/nouveau/nvc0/nvc0_surface
On Mon, Nov 09, 2015 at 11:50:25AM -0800, Kenneth Graunke wrote:
> On Saturday, November 07, 2015 08:40:51 AM Ben Widawsky wrote:
> > On Fri, Nov 06, 2015 at 07:29:18PM -0800, Kenneth Graunke wrote:
> > > On Friday, November 06, 2015 06:12:27 PM Ben Widawsky wrote:
> > > > The comment in the code d
On Mon, Nov 9, 2015 at 2:58 PM, Samuel Pitoiset
wrote:
>
>
> On 11/09/2015 07:40 PM, Ilia Mirkin wrote:
>>
>> Signed-off-by: Ilia Mirkin
>> ---
>> docs/GL3.txt| 2 +-
>> docs/relnotes/11.1.0.html | 1 +
>> src/gallium/drivers/nouveau
On Tue, Nov 3, 2015 at 11:53 PM, Kenneth Graunke wrote:
> On Wednesday, October 21, 2015 03:58:17 PM Matt Turner wrote:
>> ---
>> src/mesa/drivers/dri/i965/brw_eu_validate.c | 244
>>
>> 1 file changed, 244 insertions(+)
>>
>> diff --git a/src/mesa/drivers/dri/i965/b
Am 09.11.2015 um 19:40 schrieb Ilia Mirkin:
> This is basically a resend of a series I wrote over a year ago. I
> don't remember what we hated about it last time, but I'm tempted not
> to look. This seems pretty reasonably to me now.
I guess I wasn't entirely happy with yet another clear method...
On Mon, Nov 9, 2015 at 3:07 PM, Roland Scheidegger wrote:
> Am 09.11.2015 um 19:40 schrieb Ilia Mirkin:
>> This is basically a resend of a series I wrote over a year ago. I
>> don't remember what we hated about it last time, but I'm tempted not
>> to look. This seems pretty reasonably to me now.
>
On 11/09/2015 09:03 PM, Ilia Mirkin wrote:
On Mon, Nov 9, 2015 at 2:58 PM, Samuel Pitoiset
wrote:
On 11/09/2015 07:40 PM, Ilia Mirkin wrote:
Signed-off-by: Ilia Mirkin
---
docs/GL3.txt| 2 +-
docs/relnotes/11.1.0.html | 1 +
On Mon, Nov 9, 2015 at 3:13 PM, Samuel Pitoiset
wrote:
>
>
> On 11/09/2015 09:03 PM, Ilia Mirkin wrote:
>>
>> On Mon, Nov 9, 2015 at 2:58 PM, Samuel Pitoiset
>> wrote:
>>>
>>>
>>>
>>> On 11/09/2015 07:40 PM, Ilia Mirkin wrote:
Signed-off-by: Ilia Mirkin
---
docs/GL3.t
On 11/09/2015 09:14 PM, Ilia Mirkin wrote:
On Mon, Nov 9, 2015 at 3:13 PM, Samuel Pitoiset
wrote:
On 11/09/2015 09:03 PM, Ilia Mirkin wrote:
On Mon, Nov 9, 2015 at 2:58 PM, Samuel Pitoiset
wrote:
On 11/09/2015 07:40 PM, Ilia Mirkin wrote:
Signed-off-by: Ilia Mirkin
---
docs/G
On 10 November 2015 at 00:30, Roland Scheidegger wrote:
> Am 09.11.2015 um 04:44 schrieb Dave Airlie:
>> So it appears my patch to enable front buffer access on soft/llvmpipe
>> causes some piglit regressions. However these are due to piglit having
>> undefined behaviour where it doesn't create a
On Wed 04 Nov 2015, Jason Ekstrand wrote:
> This little patch series converts fs_surface_builder to use native formats
> for doing all of its image_load_store workaround tricks. If you're willing
> to take as an axiom that we want to not link the backend compiler against
> core mesa, this leaves u
On Wed 04 Nov 2015, Jason Ekstrand wrote:
> Previously, we were relying on has_matching_typed_format returning true for
> MESA_FORMAT_NONE which, in turn, relied on _mesa_get_format_bytes returning
> 1 for MESA_FORMAT_NONE. All of this is extremely non-obvious. Instead,
> this commit makes us han
On Wed 04 Nov 2015, Jason Ekstrand wrote:
> Eventually, we'll switch over to this new function and delete the old one
> completely. However, duplicating it both makes the transition smoother and
> allows us to assert that they are the same.
>
> While we're at it, we start a new file for collectin
On Wed 04 Nov 2015, Jason Ekstrand wrote:
> This little data structure and associated array contains all of the image
> format metadata needed for doing image_load_store work-arounds. This way
> we can pull metadata from within the i965 driver without having to go out
> to core mesa for it. It is
Am 09.11.2015 um 21:12 schrieb Ilia Mirkin:
> On Mon, Nov 9, 2015 at 3:07 PM, Roland Scheidegger wrote:
>> Am 09.11.2015 um 19:40 schrieb Ilia Mirkin:
>>> This is basically a resend of a series I wrote over a year ago. I
>>> don't remember what we hated about it last time, but I'm tempted not
>>>
On 11/09/2015 01:15 PM, Dave Airlie wrote:
On 10 November 2015 at 00:30, Roland Scheidegger wrote:
Am 09.11.2015 um 04:44 schrieb Dave Airlie:
So it appears my patch to enable front buffer access on soft/llvmpipe
causes some piglit regressions. However these are due to piglit having
undefined
On Mon, Nov 9, 2015 at 3:29 PM, Roland Scheidegger wrote:
> Am 09.11.2015 um 21:12 schrieb Ilia Mirkin:
>> On Mon, Nov 9, 2015 at 3:07 PM, Roland Scheidegger
>> wrote:
>>> Am 09.11.2015 um 19:40 schrieb Ilia Mirkin:
This is basically a resend of a series I wrote over a year ago. I
don'
https://bugs.freedesktop.org/show_bug.cgi?id=92869
--- Comment #2 from Gustaf Ullberg ---
Thanks José,
Interesting to see that you have been working on this already. So, what is the
current status? Is the patch ready to be merged after some testing or is it
controversial or incomplete in any way
On Mon, 2015-11-09 at 07:43 -0500, Rob Clark wrote:
> On Sun, Nov 8, 2015 at 7:58 PM, Timothy Arceri
> wrote:
> > On Sun, 2015-11-08 at 15:12 -0500, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > With TGSI, the ir_variable::data.location gets fixed up to be a stage
> > > local location (rath
On 10 November 2015 at 06:36, Brian Paul wrote:
> On 11/09/2015 01:15 PM, Dave Airlie wrote:
>>
>> On 10 November 2015 at 00:30, Roland Scheidegger
>> wrote:
>>>
>>> Am 09.11.2015 um 04:44 schrieb Dave Airlie:
So it appears my patch to enable front buffer access on soft/llvmpipe
ca
On Wed 04 Nov 2015, Jason Ekstrand wrote:
> ---
> .../drivers/dri/i965/brw_fs_surface_builder.cpp| 157
> ++---
> 1 file changed, 106 insertions(+), 51 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_sur
On Wed 04 Nov 2015, Jason Ekstrand wrote:
> On Wed, Nov 4, 2015 at 5:10 PM, Ilia Mirkin wrote:
> > On Wed, Nov 4, 2015 at 8:03 PM, Jason Ekstrand wrote:
> >> ---
> >> src/mesa/drivers/dri/i965/brw_image_load_store.c | 49
> >>
> >> src/mesa/drivers/dri/i965/brw_image_lo
On Wed 04 Nov 2015, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 7 ---
> src/mesa/drivers/dri/i965/brw_fs_surface_builder.cpp | 14 ++
> src/mesa/drivers/dri/i965/brw_fs_surface_builder.h | 4 ++--
> 3 files changed, 12 insertions(+), 13
On Wed 04 Nov 2015, Jason Ekstrand wrote:
> Now that the compiler is all switched over to brw_lower_image_format and
> state-setup doesn't need it, we can get rid of the old helper.
> ---
> src/mesa/drivers/dri/i965/brw_context.h | 2 -
> src/mesa/drivers/dri/i965/brw_surface_formats.c
Signed-off-by: Jordan Justen
---
src/glsl/ir_print_visitor.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/ir_print_visitor.cpp b/src/glsl/ir_print_visitor.cpp
index b919690..211ac76 100644
--- a/src/glsl/ir_print_visitor.cpp
+++ b/src/glsl/ir_print_visitor.cpp
@@
1 - 100 of 157 matches
Mail list logo
