On 6 June 2016 at 16:30, Alejandro Piñeiro wrote:
> On 03/06/16 23:04, Dave Airlie wrote:
>> On 4 June 2016 at 03:39, Alejandro Piñeiro wrote:
>>> On 03/06/16 02:46, Dave Airlie wrote:
From: Dave Airlie
"all geometry shader output vertex count declarations in a
program must d
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Jacek Konieczny changed:
What|Removed |Added
Depends on||95530
Referenced Bugs:
https://bugs.
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Jacek Konieczny changed:
What|Removed |Added
Depends on|95530 |
Referenced Bugs:
https://bugs.freed
On 06/06/16 09:00, Dave Airlie wrote:
> On 6 June 2016 at 16:30, Alejandro Piñeiro wrote:
>> On 03/06/16 23:04, Dave Airlie wrote:
>>> On 4 June 2016 at 03:39, Alejandro Piñeiro wrote:
On 03/06/16 02:46, Dave Airlie wrote:
> From: Dave Airlie
>
> "all geometry shader output vert
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Davin McCall changed:
What|Removed |Added
Depends on||80419
Referenced Bugs:
https://bugs.fre
On 06/06/16 09:44, Alejandro Piñeiro wrote:
> On 06/06/16 09:00, Dave Airlie wrote:
>> On 6 June 2016 at 16:30, Alejandro Piñeiro wrote:
>>> On 03/06/16 23:04, Dave Airlie wrote:
On 4 June 2016 at 03:39, Alejandro Piñeiro wrote:
> On 03/06/16 02:46, Dave Airlie wrote:
>> From: Dave A
A first thread binds an API and creates a context. If a second thread calls
eglMakeCurrent with the same context as parameter without having bound the
same API, the context is not linked correctly as the CurrentAPIIndex
variable as never been set.
---
src/egl/main/eglcontext.c | 1 +
1 file change
Hello,
For some OpenGL visualization module inside VLC media player, we create the
OpenGL context in one initialization thread and render in an other one.
I discovered that with Mesa EGL, eglMakeCurrent did not let me draw inside the
rendering thread. Even if eglMakeCurrent returns EGL_SUCCESS,
On 03.06.2016 19:52, Marek Olšák wrote:
> From: Marek Olšák
>
> Simply ignore the "scanout" flag if the surface dimensions are unlikely
> to be used by DCE.
I don't like this.
Ideally, there should be feedback from the display server so that he
state tracker(s) can set the PIPE_BIND_SCANOUT fla
On 04.06.2016 00:10, Marek Olšák wrote:
> On Fri, Jun 3, 2016 at 4:33 PM, Dieter Nützel wrote:
>> Am 03.06.2016 11:47, schrieb Michel Dänzer:
>>>
>>> On 03.06.2016 18:34, Marek =?UNKNOWN?B?T2zFocOhaw==?= wrote:
Module: Mesa
Branch: master
Commit: 8c361e84ad010552a42593fad4130be
On Mon, Jun 6, 2016 at 10:58 AM, Michel Dänzer wrote:
> On 03.06.2016 19:52, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> Simply ignore the "scanout" flag if the surface dimensions are unlikely
>> to be used by DCE.
>
> I don't like this.
>
> Ideally, there should be feedback from the display se
On 6 June 2016 at 10:10, Michel Dänzer wrote:
> On 04.06.2016 00:10, Marek Olšák wrote:
>> On Fri, Jun 3, 2016 at 4:33 PM, Dieter Nützel wrote:
>>> Am 03.06.2016 11:47, schrieb Michel Dänzer:
On 03.06.2016 18:34, Marek =?UNKNOWN?B?T2zFocOhaw==?= wrote:
>
> Module: Mesa
> Bra
On 04/06/16 20:36, Rob Clark wrote:
On Fri, Jun 3, 2016 at 8:53 AM, Rob Clark wrote:
Ok, so I had a really evil thought that I wanted to bounce off
people.. it's a quite different approach from the more obvious one
discussed below (and which I've already started implementing)
Basically, idea
Le 06/06/2016 à 11:19, Emil Velikov a écrit :
> Fully agree behind that one.
>
> On the overall topic here is a (related) idea I've had lying around:
> - Contact distribution maintainers to patch their glamor packages as
> far back as possible.
> Having a mesa-maintainers ML or alike might help,
On 06.06.2016 18:14, Marek Olšák wrote:
> On Mon, Jun 6, 2016 at 10:58 AM, Michel Dänzer wrote:
>> On 03.06.2016 19:52, Marek Olšák wrote:
>>> From: Marek Olšák
>>>
>>> Simply ignore the "scanout" flag if the surface dimensions are unlikely
>>> to be used by DCE.
>>
>> I don't like this.
>>
>> Id
On 06/06/2016 12:19 PM, Emil Velikov wrote:
On 6 June 2016 at 10:10, Michel Dänzer wrote:
On 04.06.2016 00:10, Marek Olšák wrote:
On Fri, Jun 3, 2016 at 4:33 PM, Dieter Nützel wrote:
Am 03.06.2016 11:47, schrieb Michel Dänzer:
On 03.06.2016 18:34, Marek =?UNKNOWN?B?T2zFocOhaw==?= wrote:
On 02/06/16 15:15, Rob Clark wrote:
From: Rob Clark
Unused, and fixes a couple of coverity warnings: CID 1362171, 1362170
Signed-off-by: Rob Clark
---
src/gallium/auxiliary/Makefile.sources | 2 -
src/gallium/auxiliary/util/u_staging.c | 136 -
src/galliu
On Mon, Jun 6, 2016 at 11:10 AM, Michel Dänzer wrote:
> On 04.06.2016 00:10, Marek Olšák wrote:
>> On Fri, Jun 3, 2016 at 4:33 PM, Dieter Nützel wrote:
>>> Am 03.06.2016 11:47, schrieb Michel Dänzer:
On 03.06.2016 18:34, Marek =?UNKNOWN?B?T2zFocOhaw==?= wrote:
>
> Module: Mesa
>
On 06/06/2016 11:37, Michel Dänzer wrote :
With DRI3, st/dri could (re-)allocate buffers with the scanout flag
first and after any window geometry changes, then re-allocate without
the flag if the present complete event indicates that page flipping
couldn't be used.
That sounds like a bad id
On 06.06.2016 18:44, Axel Davy wrote:
> On 06/06/2016 11:37, Michel Dänzer wrote :
>> With DRI3, st/dri could (re-)allocate buffers with the scanout flag
>> first and after any window geometry changes, then re-allocate without
>> the flag if the present complete event indicates that page flipping
>
Hello
I would like to keep the number of lines displayed at
http://patchwork.freedesktop.org/project/mesa/patches/?submitter=15850
to a low number.
0 is the best, 1 or 2 is meh...ok, 3+ is too much. Seeing 0 lines
allows me to move on and start working on the next patch.
From my viewpoint, the i
On Mon, Jun 6, 2016 at 11:47 AM, Michel Dänzer wrote:
> On 06.06.2016 18:44, Axel Davy wrote:
>> On 06/06/2016 11:37, Michel Dänzer wrote :
>>> With DRI3, st/dri could (re-)allocate buffers with the scanout flag
>>> first and after any window geometry changes, then re-allocate without
>>> the flag
On 06/06/2016 02:04 AM, Francisco Jerez wrote:
Vedran Miletić writes:
Aside from working just like NVIDIA and AMD proprietary stacks, no.
However, what we do right now is most certainly broken. Consider the
following argument
-I"/foo bar/baz"
which is going to be sent to Clang as two argume
On Mon, Jun 6, 2016 at 12:24 PM, Marek Olšák wrote:
> On Mon, Jun 6, 2016 at 11:47 AM, Michel Dänzer wrote:
>> On 06.06.2016 18:44, Axel Davy wrote:
>>> On 06/06/2016 11:37, Michel Dänzer wrote :
With DRI3, st/dri could (re-)allocate buffers with the scanout flag
first and after any win
I'm pretty sure someone told you this already. But you need to remove
that symbol and just use your name. Note the symbol also seems to be
casing your name to be removed in patchwork.
On Mon, 2016-06-06 at 12:11 +0200, ⚛ wrote:
> Hello
>
> I would like to keep the number of lines displayed at
> h
On Mon, Jun 6, 2016 at 12:29 PM, Timothy Arceri
wrote:
> I'm pretty sure someone told you this already. But you need to remove
> that symbol and just use your name. Note the symbol also seems to be
> casing your name to be removed in patchwork.
There's no causal relationship between a name and su
On Wed, Jun 1, 2016 at 7:07 PM, Marek Olšák wrote:
> On Wed, Jun 1, 2016 at 6:06 PM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
>> On Wed, Jun 1, 2016 at 3:53 PM, Marek Olšák wrote:
>>> Because of external factors you can't predict, your driver suddenly
>>> receives a bunch of shaders that take 2000 ms
Change MESA into Mesa in CL_PLATFORM_VERSION and CL_DEVICE_VERSION. For
both, always append git version suffix from git_sha1.h.
v5: move semicolon to same line as MESA_GIT_SHA1.
v4: drop #ifdef guards.
v3: add missing include.
v2: change CL_DEVICE_VERSION as well.
Reviewed-by: Francisco Jerez
--
Hi Laurent,
On 6 June 2016 at 10:25, Laurent Carlier wrote:
> Le 06/06/2016 à 11:19, Emil Velikov a écrit :
>> Fully agree behind that one.
>>
>> On the overall topic here is a (related) idea I've had lying around:
>> - Contact distribution maintainers to patch their glamor packages as
>> far ba
Le 06/06/2016 12:28, Marek Olšák a écrit :
On Mon, Jun 6, 2016 at 12:24 PM, Marek Olšák wrote:
On Mon, Jun 6, 2016 at 11:47 AM, Michel Dänzer wrote:
On 06.06.2016 18:44, Axel Davy wrote:
On 06/06/2016 11:37, Michel Dänzer wrote :
With DRI3, st/dri could (re-)allocate buffers with the scanou
On Mon, Jun 6, 2016 at 12:40 PM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
> I apologize for the confusion. I won't happen again.
Typo: "I won't ..." -> "It won't ..."
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailm
Hi Jan,
Fwiw I fully agree on your point on outstanding patches.
Now about this patch itself.
On 2 June 2016 at 18:41, Jan Ziak (⚛) <0xe2.0x9a.0...@gmail.com> wrote:
> LTO compilation can sometimes fail with GCC 4.9 and GCC 5.3 because
> src/mapi uses unusual mixing of C code and assembly code.
On 30/05/16 13:46, Emil Velikov wrote:
From: Emil Velikov
Analogous to the previous commit
Cc: Brian Paul
Cc: Jose Fonseca
Signed-off-by: Emil Velikov
---
Note: this may cause "false positives" if one extracts the release
tarball in another git repository. This is a preexisting bug, which w
On Mon, Jun 6, 2016 at 1:12 PM, Emil Velikov wrote:
>
> Hi Jan,
>
> Fwiw I fully agree on your point on outstanding patches.
>
> Now about this patch itself.
>
> On 2 June 2016 at 18:41, Jan Ziak (⚛) <0xe2.0x9a.0...@gmail.com> wrote:
> > LTO compilation can sometimes fail with GCC 4.9 and GCC 5.3
Gentle ping, I would appreciate a Gallium developer's eyes on this.
Regards,
Lars Hamre
On Thu, May 26, 2016 at 6:30 PM, Lars Hamre wrote:
> Switches to using truncf in micro_trunc.
>
> Fixes the following piglit tests (for softpipe):
>
> /spec/glsl-1.30/execution/built-in-functions/...
> fs-tru
v2:
- ES version check (Tapani Pälli)
v3/v4:
- compare varying slot locations rather than names (Ilia Mirkin)
The conditions for which certain built-in special variables
can be declared invariant were not being checked.
GLSL ES 1.00 specification, Section "Invariance and linkage" says:
For the
This doesn't seem to affect me using GCC 6.1 and gold
On Thu, 2 Jun 2016, 6:42 p.m. Jan Ziak (⚛), <0xe2.0x9a.0...@gmail.com>
wrote:
> LTO compilation can sometimes fail with GCC 4.9 and GCC 5.3 because
> src/mapi uses unusual mixing of C code and assembly code. The issue
> may be present in case
Reviewed-by: Iago Toral Quiroga
On Sat, 2016-06-04 at 01:09 +0200, Jakob Sinclair wrote:
> Could cause issues if you tried to read from an uninitialised pointer.
> This just initalises the pointer to null to avoid that being a problem.
> Discovered by Coverity.
>
> CID: 1343616
>
> Signed-off-b
Reviewed-by: Roland Scheidegger
I suppose we could use a wrapper like for rintf, using sse41 round
instructions directly. However, just for softpipe it doesn't sound like
it would be worth it, noone is really interested in peformance for
softpipe (and noone compiles with sse41 flag anyway).
Pushe
On 6 June 2016 at 13:01, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
> On Mon, Jun 6, 2016 at 1:12 PM, Emil Velikov wrote:
>>
>> Hi Jan,
>>
>> Fwiw I fully agree on your point on outstanding patches.
>>
>> Now about this patch itself.
>>
>> On 2 June 2016 at 18:41, Jan Ziak (⚛) <0xe2.0x9a.0...@gmail.com>
On Mon, Jun 6, 2016 at 5:19 AM, Jose Fonseca wrote:
> On 04/06/16 20:36, Rob Clark wrote:
>>
>> On Fri, Jun 3, 2016 at 8:53 AM, Rob Clark wrote:
>>>
>>> Ok, so I had a really evil thought that I wanted to bounce off
>>> people.. it's a quite different approach from the more obvious one
>>> discu
Alright, let's drop this patch. I'd still like to push patches 1-3
since they enable DCC for any shared texture without the scanout flag.
Marek
On Mon, Jun 6, 2016 at 12:47 PM, Axel Davy wrote:
> Le 06/06/2016 12:28, Marek Olšák a écrit :
>>
>> On Mon, Jun 6, 2016 at 12:24 PM, Marek Olšák wrote
On 03.06.2016 12:52, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_pipe_common.h | 4
src/gallium/drivers/radeon/r600_texture.c | 16 +++---
src/gallium/drivers/radeonsi/si_state.c | 32 ++-
3 files changed, 48 inse
This fixes the following piglits on nvc0 (tested on GK106, and should
work like a charm on Fermi as well):
- spec/mesa_pack_invert/mesa_pack_invert-readpixels/PBO unorm BGRA
- spec/arb_pixel_buffer_object/fbo-pbo-readpixels-small
- spec/arb_pixel_buffer_object/pbo-read-argb
- spec/arb_pixel_
On Tue, May 10, 2016 at 10:20 AM, Michel Dänzer wrote:
> On 10.05.2016 13:00, Nicolai Hähnle wrote:
>> On 30.04.2016 05:26, Michel Dänzer wrote:
>>> On 28.04.2016 10:54, Michel Dänzer wrote:
On 23.04.2016 07:24, Marek Olšák wrote:
> On Fri, Apr 22, 2016 at 11:28 PM, Nicolai Hähnle
>
Not surprising that code emission for VOTE was not totally correct
because it was first attempt in that area and it was just impossible to
test.
Assuming that now this thing is correct, this patch is:
Reviewed-by: Samuel Pitoiset
On 05/29/2016 08:01 PM, Ilia Mirkin wrote:
Signed-off-by: Ili
On 03.06.2016 12:52, Marek Olšák wrote:
We can save some bandwidth and power with this. It also enables fast clear for
some windowed apps on Stoney.
If you update radeonsi_dri.so but not restart X while using DRI3, X won't be
able to display drawables correctly. (e.g. firefox will display garb
Patches 1 & 2:
Reviewed-by: Nicolai Hähnle
On 03.06.2016 12:52, Marek Olšák wrote:
From: Marek Olšák
We don't import textures with DCC now, but soon we will.
---
src/gallium/drivers/radeon/r600_pipe_common.h | 2 +-
src/gallium/drivers/radeon/r600_texture.c | 31 +++--
I guess this makes sense:
Reviewed-by: Iago Toral Quiroga From: Dave Airlie
>
> This fixes a crash in
> GL43-CTS.shader_subroutine.subroutines_not_allowed_as_variables_constructors_and_argument_or_return_types
>
> If we can't find the func_name in one of these paths,
> we have emitted an earlie
On 06.06.2016 16:16, Nicolai Hähnle wrote:
Patches 1 & 2:
Reviewed-by: Nicolai Hähnle
Hold off on patch #2 - how does this work together with shader image
writes? Then we're in an ugly situation where the other process could
write to DCC, but we still need to decompress while the texture is
AMD folk - can you confirm that this will work with radeonsi?
Unfortunately we don't support all RT formats as images in nvc0 right
now.
On Mon, Jun 6, 2016 at 10:10 AM, Samuel Pitoiset
wrote:
> This fixes the following piglits on nvc0 (tested on GK106, and should work
> like a charm on Fermi as
Makes sense.
Reviewed-by: Nicolai Hähnle
On 06.06.2016 00:59, Ilia Mirkin wrote:
ARB_shader_image_load_store only requires a very fixed list of formats
to be supported, while textures may be in all kinds of formats, like
BGRA which are presently not supported on at least Kepler.
Signed-off-by
On Mon, Jun 6, 2016 at 4:14 PM, Nicolai Hähnle wrote:
> On 03.06.2016 12:52, Marek Olšák wrote:
>>
>> We can save some bandwidth and power with this. It also enables fast clear
>> for some windowed apps on Stoney.
>>
>> If you update radeonsi_dri.so but not restart X while using DRI3, X won't
>> b
On 2016-06-06 15:48, Iago Toral wrote:
Reviewed-by: Iago Toral Quiroga
I don't have push access so I would be very happy if you could push this
patch for me. Thanks!
--
Mvh Jakob Sinclair
On Sat, 2016-06-04 at 01:09 +0200, Jakob Sinclair wrote:
Could cause issues if you tried to read fro
From: Marek Olšák
We don't import textures with DCC now, but soon we will.
v2: if we can't disable DCC for image writes, at least decompress DCC
at bind time
---
src/gallium/drivers/radeon/r600_pipe_common.h | 2 +-
src/gallium/drivers/radeon/r600_texture.c | 31 +++
On Mon, Jun 6, 2016 at 4:21 PM, Nicolai Hähnle wrote:
> On 06.06.2016 16:16, Nicolai Hähnle wrote:
>>
>> Patches 1 & 2:
>>
>> Reviewed-by: Nicolai Hähnle
>
>
> Hold off on patch #2 - how does this work together with shader image writes?
> Then we're in an ugly situation where the other process co
On 06.06.2016 00:28, Bas Nieuwenhuizen wrote:
This fixes a problem with the CE preamble and restoring only stuff in the
preamble when needed.
To illustrate suppose we have two graphics IB's 1 and 2, which are submitted in
that order. Furthermore suppose IB 1 does not use CE ram, but IB 2 does,
From: Marek Olšák
v2: use a function for calculating WORD1 of bo metadata
---
src/gallium/drivers/radeon/r600_pipe_common.h | 4 +++
src/gallium/drivers/radeon/r600_texture.c | 16 +---
src/gallium/drivers/radeonsi/si_state.c | 35 ++-
3 files changed,
On Mon, Jun 6, 2016 at 5:12 PM, Bas Nieuwenhuizen
wrote:
> On Mon, Jun 6, 2016 at 4:21 PM, Nicolai Hähnle wrote:
>> On 06.06.2016 16:16, Nicolai Hähnle wrote:
>>>
>>> Patches 1 & 2:
>>>
>>> Reviewed-by: Nicolai Hähnle
>>
>>
>> Hold off on patch #2 - how does this work together with shader image
Reviewed-by: Marek Olšák
Marek
On Mon, Jun 6, 2016 at 4:29 PM, Nicolai Hähnle wrote:
> Makes sense.
>
> Reviewed-by: Nicolai Hähnle
>
>
> On 06.06.2016 00:59, Ilia Mirkin wrote:
>>
>> ARB_shader_image_load_store only requires a very fixed list of formats
>> to be supported, while textures may
Patches 1 & 3:
Reviewed-by: Nicolai Hähnle
On 05.06.2016 17:07, Marek Olšák wrote:
Hi,
The shader-based resolve is slow.
With this series, one scene with 8xMSAA in HL2: Lost Coast goes from 8-9 FPS to 32
FPS on Evergreen & Wine/Nine.
Please review.
Marek
__
On 06/05/2016 12:24 AM, Ilia Mirkin wrote:
In the case where we can't guess the base level size, just use the first
image's dims. The width0/height0/depth0 on stObj may not have been set
at this point. Observed in a trace that set up levels 2..9 of a 2d texture,
and set the base level to 2, with
On Mon, Jun 6, 2016 at 5:14 PM, Nicolai Hähnle wrote:
> On 06.06.2016 00:28, Bas Nieuwenhuizen wrote:
>>
>> This fixes a problem with the CE preamble and restoring only stuff in the
>> preamble when needed.
>>
>> To illustrate suppose we have two graphics IB's 1 and 2, which are
>> submitted in
>
On Mon, Jun 6, 2016 at 11:37 AM, Brian Paul wrote:
> On 06/05/2016 12:24 AM, Ilia Mirkin wrote:
>>
>> In the case where we can't guess the base level size, just use the first
>> image's dims. The width0/height0/depth0 on stObj may not have been set
>> at this point. Observed in a trace that set up
On 06/06/2016 10:05 AM, Ilia Mirkin wrote:
On Mon, Jun 6, 2016 at 11:37 AM, Brian Paul wrote:
On 06/05/2016 12:24 AM, Ilia Mirkin wrote:
In the case where we can't guess the base level size, just use the first
image's dims. The width0/height0/depth0 on stObj may not have been set
at this poin
https://bugs.freedesktop.org/show_bug.cgi?id=96408
Bug ID: 96408
Summary: [PERF] SSO: dirty all stages when only one is updated.
Trigger extra validations.
Product: Mesa
Version: git
Hardware: Other
OS: All
On Mon, Jun 6, 2016 at 3:39 PM, Mike Lothian wrote:
>
> This doesn't seem to affect me using GCC 6.1 and gold
I don't have GCC 6.1 installed at the moment, and it takes quite long
to install it on Gentoo.
Can you please send me the output of the following command?
$ cd mesa/src/mapi
$ make clea
On Mon, Jun 6, 2016 at 12:52 PM, Brian Paul wrote:
> On 06/06/2016 10:05 AM, Ilia Mirkin wrote:
>>
>> On Mon, Jun 6, 2016 at 11:37 AM, Brian Paul wrote:
>>>
>>> On 06/05/2016 12:24 AM, Ilia Mirkin wrote:
In the case where we can't guess the base level size, just use the first
[+ dri-devel]
On Mon, Jun 6, 2016 at 8:42 AM, Mathieu Malaterre wrote:
> Hi,
>
> Before reporting a possible invalid bug report. Does anyone knows why
> radeaonfb is not configured the same way radeon is ? For instance on a
> PowerPC machine, when Open Firmware Frame Buffer is used (OFfb), I
> ca
https://bugs.freedesktop.org/show_bug.cgi?id=96410
Bug ID: 96410
Summary: [Perf] Pre validate
_mesa_sampler_uniforms_pipeline_are_valid like
_mesa_sampler_uniforms_are_valid
Product: Mesa
Version: git
Ha
On Mon, Jun 6, 2016 at 1:16 PM, Marek Olšák wrote:
> [+ dri-devel]
>
> On Mon, Jun 6, 2016 at 8:42 AM, Mathieu Malaterre wrote:
>> Hi,
>>
>> Before reporting a possible invalid bug report. Does anyone knows why
>> radeaonfb is not configured the same way radeon is ? For instance on a
>> PowerPC m
Both are
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
This way the the bind map (which we're caching) is mostly independent of
the pipeline layout. The only coupling remaining is that we pull the array
size of a binding out of the layout. However, that size is also specified
in the shader and should always match so it's not really coupled. This
ren
Since applications are allowed to specify some set of bindings which need
not be dense they also need not be in order. For most things, this doesn't
matter, but it could result getting the wrong dynamic offsets. This adds a
quick-and-dirty sort to ensure that everything is always in increasing
ord
This allows for some extra validation and makes it easier to see what's
going on when poking around in gdb.
Signed-off-by: Jason Ekstrand
Cc: Kristian Høgsberg Kristensen
---
src/intel/vulkan/anv_descriptor_set.c | 5 +
src/intel/vulkan/anv_private.h| 5 +
2 files changed, 10 in
Signed-off-by: Jason Ekstrand
Cc: Kristian Høgsberg Kristensen
---
src/intel/vulkan/anv_descriptor_set.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/intel/vulkan/anv_descriptor_set.c
b/src/intel/vulkan/anv_descriptor_set.c
index f7a9cb0..3924d04 100644
--- a/src/intel/vulkan/anv_des
This gets ANV_ENABLE_PIPELINE_CACHE=false working again.
Signed-off-by: Jason Ekstrand
Cc: Kristian Høgsberg Kristensen
---
src/intel/vulkan/anv_pipeline_cache.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_pipeline_cache.c
b/src/intel/vulkan/anv
I'm running Gentoo too, it didn't take significantly longer to compile GCC
6.1 than any other version of GCC
I use portage to compile mesa
On Mon, 6 Jun 2016, 5:58 p.m. ⚛, <0xe2.0x9a.0...@gmail.com> wrote:
> On Mon, Jun 6, 2016 at 3:39 PM, Mike Lothian wrote:
> >
> > This doesn't seem to affect
https://bugs.freedesktop.org/show_bug.cgi?id=94512
--- Comment #7 from EoD ---
Created attachment 124376
--> https://bugs.freedesktop.org/attachment.cgi?id=124376&action=edit
LD_DEBUG=libs startx
(In reply to Emil Velikov from comment #6)
> Based of the backtrace there is no information if mes
Like floats, we should use the round toward 0 mode instead of the
nearest one (which is the default) for doubles to integers.
This fixes all arb_gpu_shader_fp64 piglits which convert doubles to
integers (16 tests).
Signed-off-by: Samuel Pitoiset
Cc: "11.2 12.0"
---
src/gallium/drivers/nouveau/
Hi Jason
Am 06/06/2016 um 20:26 schrieb Jason Ekstrand:
> This way the the bind map (which we're caching) is mostly independent of
double the here
> the pipeline layout. The only coupling remaining is that we pull the array
> size of a binding out of the layout. However, that size is also specif
Hi Jason,
Am 06/06/2016 um 20:26 schrieb Jason Ekstrand:
> Since applications are allowed to specify some set of bindings which need
> not be dense they also need not be in order.
That sentence reads strange. "Need not be" sounds like must not. Dont
you mean "Do not need to be"?
--Michael
For
On Mon, Jun 6, 2016 at 3:25 PM, Samuel Pitoiset
wrote:
> Like floats, we should use the round toward 0 mode instead of the
> nearest one (which is the default) for doubles to integers.
>
> This fixes all arb_gpu_shader_fp64 piglits which convert doubles to
> integers (16 tests).
>
> Signed-off-by:
On 03.06.2016 17:14, Marek Olšák wrote:
From: Marek Olšák
Ported from Vulkan.
---
src/gallium/drivers/radeonsi/si_state_draw.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c
b/src/gallium/drivers/radeonsi/si_state
On 7 June 2016 at 00:17, Iago Toral wrote:
> I guess this makes sense:
> Reviewed-by: Iago Toral Quiroga
> Out of curiosity, in which case do we get here and can't find a function
> name?
The test does something illegal earlier, but we keep parsing it, the case
we end up here is with id->oper be
On Mon, Jun 6, 2016 at 9:01 PM, Mike Lothian wrote:
>
> I'm running Gentoo too, it didn't take significantly longer to compile GCC
> 6.1 than any other version of GCC
>
> I use portage to compile mesa
Ok. What is the output of a command like:
$ ls --sort=time /var/log/portage/media-libs:mesa-*.
I only have /var/log/portage/elog/ the file(s) you specified don't exist on
my system
On Mon, 6 Jun 2016 at 21:13 ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
> On Mon, Jun 6, 2016 at 9:01 PM, Mike Lothian wrote:
> >
> > I'm running Gentoo too, it didn't take significantly longer to compile
> GCC 6.1 tha
For the series:
Reviewed-by: Marek Olšák
Marek
On Fri, Jun 3, 2016 at 7:01 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> Reduces CPU load for draw calls that change none or few of the descriptors.
> ---
> src/gallium/drivers/radeonsi/si_descriptors.c | 39
> --
This fixes a problem with the CE preamble and restoring only stuff in the
preamble when needed.
To illustrate suppose we have two graphics IB's 1 and 2, which are submitted in
that order. Furthermore suppose IB 1 does not use CE ram, but IB 2 does, and we
have a context switch at the start of IB
From: Nicolai Hähnle
When an applications specifies mip levels _before_ setting a mipmap texture
filter, we will initially guess a single texture level. When the second level
image is created, we try to allocate the full texture -- however, we get the
base level size guess wrong if that size is o
Now that we emit guards for everything, we can just generate the files and
trust build flags to keep us safe. This should also fix the tarball
problems.
---
src/intel/vulkan/Makefile.am | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/src/intel/vulkan/Makefile.a
---
src/intel/vulkan/anv_entrypoints_gen.py | 32 ++--
1 file changed, 22 insertions(+), 10 deletions(-)
diff --git a/src/intel/vulkan/anv_entrypoints_gen.py
b/src/intel/vulkan/anv_entrypoints_gen.py
index 7a47372..546829f 100644
--- a/src/intel/vulkan/anv_entrypoints
On 05.06.2016 08:24, Ilia Mirkin wrote:
In the case where we can't guess the base level size, just use the first
image's dims. The width0/height0/depth0 on stObj may not have been set
at this point. Observed in a trace that set up levels 2..9 of a 2d texture,
and set the base level to 2, with hei
This matches what we've been doing since you reworked the extension
string handling. This series is
Reviewed-by: Ian Romanick
On 06/03/2016 11:04 AM, Nanley Chery wrote:
> From: Nanley Chery
>
> Signed-off-by: Nanley Chery
> ---
> docs/devinfo.html | 1 +
> 1 file changed, 1 insertion(+)
>
On Mon, Jun 6, 2016 at 5:37 PM, Nicolai Hähnle wrote:
> On 05.06.2016 08:24, Ilia Mirkin wrote:
>>
>> In the case where we can't guess the base level size, just use the first
>> image's dims. The width0/height0/depth0 on stObj may not have been set
>> at this point. Observed in a trace that set up
On 05/29/2016 11:01 AM, Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin
> ---
> src/compiler/glsl/builtin_functions.cpp| 22
> ++
> src/compiler/glsl/glcpp/glcpp-parse.y | 3 +++
> src/compiler/glsl/glsl_parser_extras.cpp | 1 +
> src/comp
Thanks. In the v2 versions, patch 2 & 3 are also
Reviewed-by: Nicolai Hähnle
On 06.06.2016 17:21, Marek Olšák wrote:
From: Marek Olšák
v2: use a function for calculating WORD1 of bo metadata
---
src/gallium/drivers/radeon/r600_pipe_common.h | 4 +++
src/gallium/drivers/radeon/r600_textur
On 06/06/2016 02:10 AM, Michel Dänzer wrote:
> On 04.06.2016 00:10, Marek Olšák wrote:
>> On Fri, Jun 3, 2016 at 4:33 PM, Dieter Nützel wrote:
>>> Am 03.06.2016 11:47, schrieb Michel Dänzer:
On 03.06.2016 18:34, Marek =?UNKNOWN?B?T2zFocOhaw==?= wrote:
>
> Module: Mesa
> Branc
On 06.06.2016 23:58, Ilia Mirkin wrote:
On Mon, Jun 6, 2016 at 5:37 PM, Nicolai Hähnle wrote:
On 05.06.2016 08:24, Ilia Mirkin wrote:
In the case where we can't guess the base level size, just use the first
image's dims. The width0/height0/depth0 on stObj may not have been set
at this point.
On Mon, Jun 6, 2016 at 6:32 PM, Nicolai Hähnle wrote:
> On 06.06.2016 23:58, Ilia Mirkin wrote:
>>
>> On Mon, Jun 6, 2016 at 5:37 PM, Nicolai Hähnle wrote:
>>>
>>> On 05.06.2016 08:24, Ilia Mirkin wrote:
In the case where we can't guess the base level size, just use the first
1 - 100 of 153 matches
Mail list logo
