https://bugs.freedesktop.org/show_bug.cgi?id=97260
Michel Dänzer changed:
What|Removed |Added
Version|unspecified |git
Component|DRM/Radeon
Matt Turner writes:
> var_range_end(v, n) loops over the n components of variable number v and
> finds the maximum value, giving the last use of any component of v.
> Therefore it expects v to correspond to the variable associated with the
> .x channel of the VGRF.
>
> var_from_reg() however retu
var_range_end(v, n) loops over the n components of variable number v and
finds the maximum value, giving the last use of any component of v.
Therefore it expects v to correspond to the variable associated with the
.x channel of the VGRF.
var_from_reg() however returns the variable for the first ch
https://bugs.freedesktop.org/show_bug.cgi?id=44519
Vinson Lee changed:
What|Removed |Added
Version|git |8.0
--
You are receiving this mail because
On 08/18/2016 04:45 PM, Ilia Mirkin wrote:
Since it *is* a hash, you could just use a much simpler hash function like
int hash(int val) {
int ret = val + 1000;
if (ret == 0) ret = 1;
return ret;
}
That way everything will map to a unique integer, except for -1000
which will map to the s
In some very specially-crafted cases, we could attempt to visit a node
that has already been visited, and then run out of bb's to visit, while
there were still cross blocks on the list. Make sure that those get
moved over in that case.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96274
S
On 08/18/2016 09:08 PM, Eric Anholt wrote:
Tapani Pälli writes:
Implementation previously used case value itself as the key, however
afterhash implementation change by ee02a5e we cannot use 0 as key.
Patch uses _mesa_hash_data to formulate a suitable key for this hash.
Signed-off-by: Tapani
https://bugs.freedesktop.org/show_bug.cgi?id=95346
--- Comment #22 from Christopher W. Carpenter ---
Forgot that the trace is too big to attach.
You can download the new trace here:
https://www.dropbox.com/s/hhtrsxq3hk1efow/stellaris_2016-08-18.trace?dl=0.
I actually go in game with it and cir
https://bugs.freedesktop.org/show_bug.cgi?id=95346
--- Comment #21 from Christopher W. Carpenter ---
Created attachment 125903
--> https://bugs.freedesktop.org/attachment.cgi?id=125903&action=edit
Dark side of planet in game windows 2016-08-18
--
You are receiving this mail because:
You are t
https://bugs.freedesktop.org/show_bug.cgi?id=95346
--- Comment #20 from Christopher W. Carpenter ---
Created attachment 125902
--> https://bugs.freedesktop.org/attachment.cgi?id=125902&action=edit
Light side of planet in game windows 2016-08-18
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=95346
--- Comment #19 from Christopher W. Carpenter ---
Created attachment 125901
--> https://bugs.freedesktop.org/attachment.cgi?id=125901&action=edit
New game screen in windows 2016-08-18
--
You are receiving this mail because:
You are the QA Con
https://bugs.freedesktop.org/show_bug.cgi?id=95346
--- Comment #18 from Christopher W. Carpenter ---
Created attachment 125900
--> https://bugs.freedesktop.org/attachment.cgi?id=125900&action=edit
Dark side of planet in game mesa master 2016-08-18
--
You are receiving this mail because:
You a
https://bugs.freedesktop.org/show_bug.cgi?id=95346
Christopher W. Carpenter changed:
What|Removed |Added
Attachment #123613|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=95346
--- Comment #16 from Christopher W. Carpenter ---
Created attachment 125898
--> https://bugs.freedesktop.org/attachment.cgi?id=125898&action=edit
New game screen with mesa master 2016-08-18
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=95346
--- Comment #15 from Christopher W. Carpenter ---
Alright, I finally got my rig back setup with the right mesa options and
everything and have new screenshots and a new API trace. Attaching these now.
I'm including windows screenshots from my wi
On 18 August 2016 at 12:59, Weng, Chuanbo wrote:
> Hi Dave and all,
> (Since Dave implemented this extension EGL_MESA_image_dma_buf_export,
> so I also send this email to you.)
> Could you please review this patch and push it if it looks good to
> you? Thanks!
I think this need
Unfortunately openmw is only a game engine and the game data or assets are
not included which are required for using it. This could make testing it
morecomplicated, however I can build mesa myself and test any patches if that
helps.
If the game data is provided this is relatively easy to reprodu
Dear Gurus,
I have downloaded the latest source code of glu lib. I have no idea how to
build it in VS 2015. There is no make file in the folder.
Could you please give me some advice?
BTW, I have already build latest mesa lib. The demo example works fine with
mesa lib and old glu32.lib given
The previous bit disables the whole clipper, including the regular
viewport-related clipping that would go on. The two new bits disable
near and far clipping (separately, as verified with the
depth-clamp-range piglit).
Signed-off-by: Ilia Mirkin
Cc: mesa-sta...@lists.freedesktop.org
---
src/gall
We were previously ... not clamping. I guess this meant that everything
got clamped to 1/0, which was enough to pass the existing tests. Or
perhaps the clamping would only happen to the rasterized depth value and
not the frag shader's output depth value.
Bugzilla: https://bugs.freedesktop.org/show
Scheduling barriers are implemented by placing a dependence on every
node before and after the barrier. This is unnecessary as we can limit
the number of nodes we place dependencies on to those between us and the
next barrier in each direction.
Runtime of dEQP-GLES31.functional.ssbo.layout.random.
On Saturday, August 6, 2016 12:28:36 AM PDT Eric Anholt wrote:
> I wanted to include this from nir_builder as well, so it also needed the
> undefs.
> ---
> src/compiler/nir/nir.h| 3 ---
> src/compiler/nir/nir_intrinsics.h | 3 +++
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
On Friday, August 5, 2016 4:22:16 PM PDT Eric Anholt wrote:
> Here's a little miniseries from my trying to convert from using TTN to
> usually using GTN in vc4. No change on shader-db, but seems like a
> good idea.
>
> Eric Anholt (3):
> nir: Tell opt_algebraic that load_front_face is a boolean
Iago Toral writes:
> On Mon, 2016-08-08 at 15:58 -0700, Francisco Jerez wrote:
>> Iago Toral Quiroga writes:
>>
>> >
>> > ---
>> > src/mesa/drivers/dri/i965/brw_disasm.c | 8 +++-
>> > 1 file changed, 7 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/src/mesa/drivers/dri/i965/brw_dis
On Thu, Aug 18, 2016 at 10:21 AM, Matt Turner wrote:
> On Thu, Aug 18, 2016 at 3:43 AM, Iago Toral wrote:
>> On Wed, 2016-08-17 at 11:54 -0700, Matt Turner wrote:
>>> The basic block following a control flow structure like an infinite
>>> loop
>>> will be unreachable. Ignore any non-control-flow
On 08/18/2016 01:56 PM, Marek Olšák wrote:
From: Marek Olšák
This improves readability a lot.
Series LGTM.
Reviewed-by: Brian Paul
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
One comment not strictly related to this patch (or any other in
particular): Apparently the spec requires some amount of draw-time error
checking you don't seem to have implemented anywhere in this series,
e.g.:
|If any non-NONE draw buffer uses a blend equation found in table X.1
|or X.2,
Here are a few fixes to get Travis CI builds on github working again.
As a reminder: If your personal branches of Mesa are on github, you
can enable it in your github account, then go to travis-ci.com, login,
go to your profile settings there, and check the Mesa repository. Any
further git pushes
---
.travis.yml | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index e086173c529f..5f489a47fb79 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -16,7 +16,11 @@ addons:
- libexpat1-dev
- libxcb-dri2-0-dev
- libx11-xcb-d
Travis has been broken a couple of times by configure.ac updates. To make
it useful, auto-update the version necessary.
This could potentially be used for other dependencies, too, but those get
bumped less frequently.
---
.travis.yml | 10 ++
1 file changed, 10 insertions(+)
diff --git
This will hopefully fix wget from x.org (no real reason explained in
Travis CI bug reports), and may also mean that we can enable LLVM driver
builds.
---
.travis.yml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/.travis.yml b/.travis.yml
index 843a9bcdc2ee..6a22e9595fe0 100
---
.travis.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.travis.yml b/.travis.yml
index 6a22e9595fe0..e086173c529f 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -89,7 +89,7 @@ install:
- wget http://dri.freedesktop.org/libdrm/$LIBDRM_VERSION.tar.bz2
- tar -jxvf
Kenneth Graunke writes:
> Many GPUs cannot handle GL_KHR_blend_equation_advanced natively, and
> need to emulate it in the pixel shader. This lowering pass implements
> all the necessary math for advanced blending. It fetches the existing
> framebuffer value using the MESA_shader_framebuffer_fe
On Thu, Aug 18, 2016 at 6:12 PM, Jason Ekstrand wrote:
> On Aug 18, 2016 23:02, "Connor Abbott" wrote:
>>
>> On Thu, Aug 18, 2016 at 2:46 PM, Kenneth Graunke
>> wrote:
>> > We want to insert the code at the end of the program. Looping over
>> > all the functions (of which there was only one) wa
On Aug 18, 2016 23:02, "Connor Abbott" wrote:
>
> On Thu, Aug 18, 2016 at 2:46 PM, Kenneth Graunke
wrote:
> > We want to insert the code at the end of the program. Looping over
> > all the functions (of which there was only one) was the old way of doing
> > this, but now we have nir_shader_get_e
On Thu, Aug 18, 2016 at 2:46 PM, Kenneth Graunke wrote:
> We want to insert the code at the end of the program. Looping over
> all the functions (of which there was only one) was the old way of doing
> this, but now we have nir_shader_get_entrypoint(), so let's use it.
>
> Suggested by Connor Abb
Thanks. Rb
On Aug 18, 2016 19:46, "Kenneth Graunke" wrote:
> We want to insert the code at the end of the program. Looping over
> all the functions (of which there was only one) was the old way of doing
> this, but now we have nir_shader_get_entrypoint(), so let's use it.
>
> Suggested by Conn
2016-08-17 3:02 GMT+02:00 Timothy Arceri :
> On Tue, 2016-08-16 at 22:10 +0200, Thomas Helland wrote:
>> This will make it functionally equivalent to the one in util.
>> This enables us to do a step-by-step replacement of the table.
>>
>> Signed-off-by: Thomas Helland
>
> You should really just mo
On Thu, Aug 18, 2016 at 2:41 PM, Tobias Klausmann
wrote:
> I have no test case per se, but orbea (in CC) noted in IRC:
>
> Start OpenMW with DRI3 -> Crash [1]
>
> Start OpenMW with DRI2 -> no crash,
>
> So i fear it is somewhere in our DRI3 path. Anyway a guard seems reasonable
> to harden release
And change the include in glcpp.h accordingly.
V2: Whitespace fix
Signed-off-by: Thomas Helland
---
src/compiler/glsl/glcpp/glcpp-parse.y | 54 ++-
src/compiler/glsl/glcpp/glcpp.h | 2 +-
2 files changed, 35 insertions(+), 21 deletions(-)
diff --git a/src
From: Marek Olšák
This improves readability a lot.
---
src/gallium/auxiliary/hud/hud_context.c | 80 ++--
src/gallium/auxiliary/hud/hud_driver_query.c | 3 +-
src/gallium/auxiliary/hud/hud_private.h | 1 +
3 files changed, 80 insertions(+), 4 deletions(-)
dif
From: Marek Olšák
this looks a lot better (with the next patch)
---
src/gallium/auxiliary/hud/hud_context.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/hud/hud_context.c
b/src/gallium/auxiliary/hud/hud_context.c
index 0b292bc..fb9c8c6 100644
--
From: Marek Olšák
---
src/gallium/auxiliary/hud/hud_context.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/src/gallium/auxiliary/hud/hud_context.c
b/src/gallium/auxiliary/hud/hud_context.c
index 8ab998e..f7baccd 100644
--- a/src/gallium/auxiliary/hud/hu
From: Marek Olšák
---
src/gallium/auxiliary/hud/hud_context.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/src/gallium/auxiliary/hud/hud_context.c
b/src/gallium/auxiliary/hud/hud_context.c
index f7baccd..ac971d8 100644
--- a/src/gallium/auxiliary/hud/hud_con
From: Marek Olšák
---
src/gallium/auxiliary/hud/hud_context.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/src/gallium/auxiliary/hud/hud_context.c
b/src/gallium/auxiliary/hud/hud_context.c
index fb9c8c6..8ab998e 100644
--- a/src/gallium/auxiliary/hud/hud_context.c
From: Marek Olšák
---
src/gallium/auxiliary/hud/hud_context.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/hud/hud_context.c
b/src/gallium/auxiliary/hud/hud_context.c
index 7870da5..0b292bc 100644
--- a/src/gallium/auxiliary/hud/hud_context.
And remove the now unused hash_table_replace.
V2: Actually do the equivalent thing, and don't leak memory
Signed-off-by: Thomas Helland
---
src/mesa/program/hash_table.h | 66 +++
1 file changed, 22 insertions(+), 44 deletions(-)
diff --git a/src/mesa/pr
From: Marek Olšák
If the kernel driver doesn't support it, it returns 0.
---
src/gallium/drivers/radeon/r600_query.c | 8 ++--
src/gallium/drivers/radeon/r600_query.h | 1 +
src/gallium/drivers/radeon/radeon_winsys.h| 1 +
src/gallium/winsys/amdgpu/drm/amdgpu_wins
From: Marek Olšák
They are harmless, but the interrupts do decrease performance.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97039
Cc: 12.0
---
src/gallium/drivers/radeonsi/si_pipe.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/gallium/driv
From: Marek Olšák
there's no reason to separate these
---
src/gallium/drivers/r600/evergreen_compute.c| 2 +-
src/gallium/drivers/r600/evergreen_state.c | 2 +-
src/gallium/drivers/r600/r600_state.c | 2 +-
src/gallium/drivers/r600/r600_state_common.c| 2 +-
src/galliu
From: Marek Olšák
---
src/gallium/drivers/radeon/radeon_winsys.h | 2 +-
src/gallium/drivers/radeonsi/si_debug.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_winsys.h
b/src/gallium/drivers/radeon/radeon_winsys.h
index cbab406..f4e37
From: Marek Olšák
SDMA is much faster for tiled->linear blits from VRAM to GTT.
I have Bonaire in my second PCIe slot.
$ glxinfo | grep OpenGL.renderer
OpenGL renderer string: Gallium 0.4 on AMD TONGA ...
$ DRI_PRIME=1 glxinfo | grep OpenGL.renderer
OpenGL renderer string: Gallium 0.4 on AMD BO
From: Marek Olšák
Invalidated buffers don't have to do this.
---
src/gallium/drivers/radeon/r600_buffer_common.c | 147 +---
src/gallium/drivers/radeon/r600_pipe_common.h | 2 +
2 files changed, 80 insertions(+), 69 deletions(-)
diff --git a/src/gallium/drivers/radeon/r6
From: Marek Olšák
This was missed while rewriting the PIPE_DUMP flags.
---
src/gallium/drivers/radeonsi/si_debug.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_debug.c
b/src/gallium/drivers/radeonsi/si_debug.c
index 7e75d3f..8ce9caf 1006
From: Marek Olšák
It passes R600_DEBUG=testdma on Bonaire/radeon.
---
src/gallium/drivers/radeonsi/cik_sdma.c | 4
1 file changed, 4 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/cik_sdma.c
b/src/gallium/drivers/radeonsi/cik_sdma.c
index a36bbce..2eade50 100644
--- a/src/gallium/
Iago Toral writes:
> On Mon, 2016-08-08 at 15:26 -0700, Francisco Jerez wrote:
>> Iago Toral Quiroga writes:
>>
>> >
>> > From the HSW PRM, Command Reference, QtrCtrl:
>> >
>> > "NibCtrl is only allowed for SIMD4 instructions with a DF
>> > (Double Float)
>> > source or destination typ
Iago Toral writes:
> On Wed, 2016-08-17 at 15:15 -0700, Francisco Jerez wrote:
>> Iago Toral writes:
>>
>> >
>> > On Tue, 2016-08-02 at 18:27 -0700, Francisco Jerez wrote:
>> > >
>> > > Iago Toral Quiroga writes:
>> > >
>> > > >
>> > > >
>> > > > ---
>> > > > src/mesa/drivers/dri/i965/br
We want to insert the code at the end of the program. Looping over
all the functions (of which there was only one) was the old way of doing
this, but now we have nir_shader_get_entrypoint(), so let's use it.
Suggested by Connor Abbott.
Signed-off-by: Kenneth Graunke
---
.../drivers/dri/i965/br
https://bugs.freedesktop.org/show_bug.cgi?id=93551
--- Comment #42 from Alex ---
(In reply to Thomas J. Moore from comment #32)
> Created attachment 125302 [details]
> Simple LD_PRELOAD shim to apply necessary patches for divos
>
> Game works great for me with the above patches (thanks to those
Tapani Pälli writes:
> Implementation previously used case value itself as the key, however
> afterhash implementation change by ee02a5e we cannot use 0 as key.
> Patch uses _mesa_hash_data to formulate a suitable key for this hash.
>
> Signed-off-by: Tapani Pälli
> Bugzilla: https://bugs.freede
From: Mathias Fröhlich
Hi,
I found the below while fixing a similar problem lately in
the immediate mode glBegin/glEnd code path.
Please review
Thanks
Mathias
When executing a display list draw with a shader program
using the generic0 attribute the offset computation
may get out of sync. To
On Thu, Aug 18, 2016 at 8:45 AM, Emil Velikov wrote:
> On 16 August 2016 at 18:01, Rob Clark wrote:
>> I noticed that fence extension wasn't exposed for drm/gbm, which sort
>> of defeats the purpose of using fence fd's for synchronizing rendering
>> and atomic pageflip.
>>
> Afaict this is a slig
On Thu, Aug 18, 2016 at 3:43 AM, Iago Toral wrote:
> On Wed, 2016-08-17 at 11:54 -0700, Matt Turner wrote:
>> The basic block following a control flow structure like an infinite
>> loop
>> will be unreachable. Ignore any non-control-flow instructions in it
>> since they can have no effect on the p
On Wed, Aug 17, 2016 at 3:03 PM, Kenneth Graunke wrote:
> load_front_face and load_helper_invocation produce booleans.
>
> On Broadwell:
>
> total instructions in shared programs: 11638956 -> 11638011 (-0.01%)
> instructions in affected programs: 115093 -> 114148 (-0.82%)
> helped: 628
> HURT: 14
Hi Christian,
I tried using 3 instances of the filter with original height & width,
height/2 & width and height/2 and width/2.
I am applying the 3 filters by checking the width and height of
surfaces respectively.
The chroma artifacts are still present, different from the initial
ones. Any sugges
https://bugs.freedesktop.org/show_bug.cgi?id=97393
Ruslan Kabatsayev changed:
What|Removed |Added
Resolution|--- |NOTABUG
Status|NEW
Don’t think it’ll help Minecraft. Looking at an apitrace of running around in
the demo world for a little bit, it only created 66 display lists all of which
were quite small (less than 100 api entries).
-Tim
> On Aug 18, 2016, at 3:10 AM, Gustaw Smolarczyk wrote:
>
> Hi,
>
> Will this help
On Wed, Aug 17, 2016 at 10:15 AM, Kenneth Graunke wrote:
> Fixes several GL44-CTS.tessellation_shader (and GL45 and ES31) subcases:
> - vertex_spacing
> - tessellation_shader_point_mode.points_verification
> - tessellation_shader_quads_tessellation.inner_tessellation_level_rounding
>
> Cc: mesa-st
https://bugs.freedesktop.org/show_bug.cgi?id=97393
--- Comment #9 from Ilia Mirkin ---
s3tc is completely disabled if libtxc_dxtn.so isn't found.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=97393
--- Comment #8 from Ruslan Kabatsayev ---
Hmm, I seem to have expressed my question badly in comment 7. I mean:
1. with s2tc library and no s3tc, i965 result is correct, and swrast result is
wrong
2. without s2tc but with s3tc library both are
https://bugs.freedesktop.org/show_bug.cgi?id=97393
--- Comment #7 from Ruslan Kabatsayev ---
(In reply to Roland Scheidegger from comment #6)
> Without having tested it, the image looks to me like it might be using s2tc
> decompression (which is what distros install due to patent issues). Which
>
https://bugs.freedesktop.org/show_bug.cgi?id=97393
--- Comment #6 from Roland Scheidegger ---
Without having tested it, the image looks to me like it might be using s2tc
decompression (which is what distros install due to patent issues). Which
cheats a bit (no interpolation between the two base c
https://bugs.freedesktop.org/show_bug.cgi?id=97393
--- Comment #5 from Ruslan Kabatsayev ---
(In reply to almos from comment #4)
> The test renders fine for me with radeonsi, llvmpipe, softpipe, swrast. Mesa
> 11.2.2 and 12.1-dev, llvm 3.8, libtxc-dxtn0 1.0.1.
That's strange... I also tested on
On Fri, Aug 12, 2016 at 01:26:08AM +0200, Marek Olšák wrote:
> From: Marek Olšák
>
> we should do that allegedly
Reviewed-by: Tom Stellard
> ---
> src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/src/gallium/drivers/radeon/radeon_s
https://bugs.freedesktop.org/show_bug.cgi?id=97393
--- Comment #4 from almos ---
The test renders fine for me with radeonsi, llvmpipe, softpipe, swrast. Mesa
11.2.2 and 12.1-dev, llvm 3.8, libtxc-dxtn0 1.0.1.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are th
On Thu, Aug 11, 2016 at 02:15:26PM -0700, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/genX_blorp_exec.c | 213
> +++-
> 1 file changed, 212 insertions(+), 1 deletion(-)
I can't see anything amiss here either:
Reviewed-by: Topi Pohjolainen
>
> diff --git a/
Ping.
This was pointed out by Matt Arsenault. gallivm_compile_module calls these
too.
Marek
On Fri, Aug 12, 2016 at 1:26 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> we should do that allegedly
> ---
> src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 2 ++
> 1 file changed, 2 insertio
https://bugs.freedesktop.org/show_bug.cgi?id=97393
--- Comment #3 from Ruslan Kabatsayev ---
(In reply to Ilia Mirkin from comment #2)
> Sounds like your test-case is doing linear interp, and that's not working in
> swrast for some reason? Haven't looked at the actual test-case yet.
No, it uses
On Thu, Aug 11, 2016 at 02:15:25PM -0700, Jason Ekstrand wrote:
> The new helper emits surface states and the binding table in one go. It's
> nice to have it pulled out of the main blorp_exec function.
> ---
> src/mesa/drivers/dri/i965/genX_blorp_exec.c | 52
> -
Revi
On Thu, Aug 11, 2016 at 02:15:24PM -0700, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/genX_blorp_exec.c | 49
> ++---
> 1 file changed, 38 insertions(+), 11 deletions(-)
Reviewed-by: Topi Pohjolainen
>
> diff --git a/src/mesa/drivers/dri/i965/genX_blorp_exe
https://bugs.freedesktop.org/show_bug.cgi?id=97393
Ilia Mirkin changed:
What|Removed |Added
Component|Drivers/Gallium/swr |Mesa core
--- Comment #2 from Ilia Mirkin
On 27 July 2016 at 16:19, Jason Ekstrand wrote:
> Thanks. We only had that because at one point we weren't using the loader
> and dota2 needed it. No longer an issue...
>
Damien, are you still keeping track of oddly parsed emails by patchwork ?
Jason's reply seems to have confused patchwork to cha
https://bugs.freedesktop.org/show_bug.cgi?id=97393
--- Comment #1 from Ruslan Kabatsayev ---
Created attachment 125876
--> https://bugs.freedesktop.org/attachment.cgi?id=125876&action=edit
Screenshot
On this screenshot LHS is the swrast result, and RHS is i965. The former is
wrong, the latter
https://bugs.freedesktop.org/show_bug.cgi?id=97393
Bug ID: 97393
Summary: Wrong result of S3TC DXT3 texture rendering
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
On Thu, Aug 11, 2016 at 02:15:23PM -0700, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/genX_blorp_exec.c | 82
> +
> 1 file changed, 73 insertions(+), 9 deletions(-)
Compared to existing and didn't see anything added or removed:
Reviewed-by: Topi Pohjolain
On Thu, Aug 18, 2016 at 9:28 AM, Emil Velikov wrote:
> On 18 August 2016 at 14:12, Rob Clark wrote:
>> On Thu, Aug 18, 2016 at 8:45 AM, Emil Velikov
>> wrote:
>>> On 16 August 2016 at 18:01, Rob Clark wrote:
I noticed that fence extension wasn't exposed for drm/gbm, which sort
of def
Since it *is* a hash, you could just use a much simpler hash function like
int hash(int val) {
int ret = val + 1000;
if (ret == 0) ret = 1;
return ret;
}
That way everything will map to a unique integer, except for -1000
which will map to the same thing as -999. I posit that this should be
On 18 August 2016 at 14:12, Rob Clark wrote:
> On Thu, Aug 18, 2016 at 8:45 AM, Emil Velikov
> wrote:
>> On 16 August 2016 at 18:01, Rob Clark wrote:
>>> I noticed that fence extension wasn't exposed for drm/gbm, which sort
>>> of defeats the purpose of using fence fd's for synchronizing render
On Thu, Aug 11, 2016 at 02:15:21PM -0700, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/Makefile.am | 1 +
> src/mesa/drivers/dri/i965/gen6_blorp.c | 685
> -
> 2 files changed, 256 insertions(+), 430 deletions(-)
>
> diff --git a/src/mesa/drivers/dri
On 08/18/2016 04:25 AM, Emil Velikov wrote:
On 17 August 2016 at 15:39, Brian Paul wrote:
We need an extra set of braces for an array inside a struct.
---
src/compiler/glsl/ast_to_hir.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compiler/glsl/ast_to_hir.cpp b/s
On Thu, Aug 18, 2016 at 8:45 AM, Emil Velikov wrote:
> On 16 August 2016 at 18:01, Rob Clark wrote:
>> I noticed that fence extension wasn't exposed for drm/gbm, which sort
>> of defeats the purpose of using fence fd's for synchronizing rendering
>> and atomic pageflip.
>>
> Afaict this is a slig
On 16 August 2016 at 18:01, Rob Clark wrote:
> I noticed that fence extension wasn't exposed for drm/gbm, which sort
> of defeats the purpose of using fence fd's for synchronizing rendering
> and atomic pageflip.
>
Afaict this is a slightly more complete version of Philipp's patch.
While my earli
I have no test case per se, but orbea (in CC) noted in IRC:
Start OpenMW with DRI3 -> Crash [1]
Start OpenMW with DRI2 -> no crash,
So i fear it is somewhere in our DRI3 path. Anyway a guard seems
reasonable to harden release builds against this. Maybe not at this
place but central in update_
On 08/18/2016 03:11 PM, Iago Toral wrote:
On Wed, 2016-08-17 at 11:18 +0300, Tapani Pälli wrote:
In case we have empty log (""), we should return 0. This fixes
Khronos WebGL conformance test 'program-infolog'.
From OpenGL ES 3.1 (and OpenGL 4.5 Core) spec:
"If pname is INFO_LOG_LENGTH , th
On Wed, 2016-08-17 at 11:18 +0300, Tapani Pälli wrote:
> In case we have empty log (""), we should return 0. This fixes
> Khronos WebGL conformance test 'program-infolog'.
>
> From OpenGL ES 3.1 (and OpenGL 4.5 Core) spec:
> "If pname is INFO_LOG_LENGTH , the length of the info log,
> including
Can the hash value not be 0?
On Aug 18, 2016 4:57 AM, "Tapani Pälli" wrote:
> Implementation previously used case value itself as the key, however
> afterhash implementation change by ee02a5e we cannot use 0 as key.
> Patch uses _mesa_hash_data to formulate a suitable key for this hash.
>
> Sign
On 08/18/2016 05:08 AM, Michel Dänzer wrote:
On 18/08/16 05:39 AM, Itai wrote:
(Posted initially in mesa-users, but got no reply - the list seems dead.
Couldn't find any bug report, and sadly not well versed enough in mesa
to file one myself).
FWIW, there's no need to be versed in Mesa to file
On Mon, 2016-08-08 at 15:26 -0700, Francisco Jerez wrote:
> Iago Toral Quiroga writes:
>
> >
> > From the HSW PRM, Command Reference, QtrCtrl:
> >
> > "NibCtrl is only allowed for SIMD4 instructions with a DF
> > (Double Float)
> > source or destination type."
> >
> > v2 (Samuel): Asser
On Thu, 2016-08-18 at 14:25 +0300, Tapani Pälli wrote:
> On 08/18/2016 01:08 PM, Iago Toral wrote:
> >
> > On Thu, 2016-08-18 at 11:57 +0300, Tapani Pälli wrote:
> > >
> > > Implementation previously used case value itself as the key,
> > > however
> > > afterhash implementation change by ee02a5e
On 08/18/2016 01:08 PM, Iago Toral wrote:
On Thu, 2016-08-18 at 11:57 +0300, Tapani Pälli wrote:
Implementation previously used case value itself as the key, however
afterhash implementation change by ee02a5e we cannot use 0 as key.
Patch uses _mesa_hash_data to formulate a suitable key for this
1 - 100 of 117 matches
Mail list logo
