https://bugs.freedesktop.org/show_bug.cgi?id=78298
NicolasChauvet changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Many instructions implicitly update the accumulator on Gen < 6. The instruction
scheduling code just calls add_barrier_deps() for each accumulator access on
these platforms, but a large class of operations don't actually update the
accumulator -- mostly move and logical instructions. Teaching the s
This only matters for TextureView where the texObj's target has not been
set yet, in all other instances, texObj->target should be the same as
the passed-in target parameter.
Signed-off-by: Ilia Mirkin
---
I ran into an assert in mesa/st when choosing the texture format because the
target was 0.
ping for this and 1/2 (which just adds the new cap)
On Mon, Apr 28, 2014 at 7:30 PM, Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin
> ---
>
> The handling of the 4 offsets is less-than-pretty. I had an alternate version
> that created a new ir_dereference_array object and ran ->accept on that.
On Tue, May 6, 2014 at 5:27 AM, Fredrik Höglund wrote:
> On Tuesday 22 April 2014, Chia-I Wu wrote:
>> Hi list,
>>
>> This series adds a thread pool to the GLSL compiler, and a drirc option to
>> defer glCompileShader calls to the pool. The goal is to reduce the start-up
>> time of applications t
On 05/06/2014 01:04 AM, Kenneth Graunke wrote:
On 05/05/2014 10:01 AM, Ian Romanick wrote:
The problem I see with that is we don't know what order constructors on
global objects will occur. Are we sure the contructor will be invoked
before we need the locale now and in the future?
These funct
On Tue, May 6, 2014 at 6:04 AM, Kenneth Graunke wrote:
> On 05/05/2014 10:01 AM, Ian Romanick wrote:
>> On 05/04/2014 02:14 PM, Chia-I Wu wrote:
>>> On Sat, May 3, 2014 at 1:52 AM, Ian Romanick wrote:
On 04/22/2014 01:58 AM, Chia-I Wu wrote:
> There may be two contexts compiling shaders
Reviewed-by: Marek Olšák
Marek
On Tue, May 6, 2014 at 5:40 AM, Bryan Cain wrote:
> With the more advanced dead code elimination pass already being run,
> eliminate_dead_code was making no difference in instruction count, and had
> an undesirable O(n^2) runtime. So remove it and rename
> elimina
Cross-compiling Mesa for windows on linux with mingw is dead easy:
- install mingw-w64 C/C++ cross-compilers (any recent linux distro already
has the packages)
- run
scons platform=windows libgl-gdi
The opengl32.dll drop-in replacement will in
mesa/build/windows-x86-debug/gallium/ta
These patches allow MAD opcode to be used with pre gen6 hardware.
Instead of failing on emitting MAD there will be emitted MUL and ADD
to simulate MAD.
I tried this with piglit on ILK (gen5) and did not see regression.
Juha-Pekka Heikkila (2):
i965/fs: Simulate MAD opcode with gen<6
i965/vec
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index d2dc5fa..22ca528 100644
--- a
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 41 ++
1 file changed, 29 insertions(+), 12 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 7bad81c..50
Add support for GLES2 extentions for floating point and half
floating point textures (GL_OES_texture_float, GL_OES_texture_half_float,
GL_OES_texture_float_linear and GL_OES_texture_half_float_linear).
---
src/mesa/main/extensions.c | 12 +
src/mesa/main/glformats.c | 27
Looks good to me.
Does that mean if also the GATHER_SM5 cap is supported you have to
support 4 independent, non-constant offsets?
Would it make sense to reorder the caps so the gather stuff is all
together (now 5 cap bits just for this...)?
Roland
Am 29.04.2014 01:30, schrieb Ilia Mirkin:
> Signe
On Tue, May 6, 2014 at 10:48 AM, Roland Scheidegger wrote:
> Looks good to me.
Thanks!
> Does that mean if also the GATHER_SM5 cap is supported you have to
> support 4 independent, non-constant offsets?
Not 100% sure what you're asking... but yes, for ARB_gs5 to work, you
have to support indepe
Series LGTM.
Jose
- Original Message -
> Remove default switch case so we're warned of missing cases at compile
> time.
> ---
> src/gallium/drivers/svga/svga_screen.c | 18 ++
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/src/gallium/drivers/svga/
Use "@GL_LIB@" in src/gallium/targets/libgl-xlib/Makefile.am to produce
the library name specified by the configure --with-gl-lib-name option.
---
src/gallium/targets/libgl-xlib/Makefile.am | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/gallium/targets/libgl
The title should be something like
mesa: Expose GL_OES_texture_float and GL_OES_texture_half_float.
Have you found an application that wants these extensions? That might
be useful to describe in the commit message.
On Tue, May 6, 2014 at 4:02 AM, Kevin Rogovin wrote:
> Add support for GLES2 ext
Juha-Pekka Heikkila writes:
> These patches allow MAD opcode to be used with pre gen6 hardware.
> Instead of failing on emitting MAD there will be emitted MUL and ADD
> to simulate MAD.
>
> I tried this with piglit on ILK (gen5) and did not see regression.
This hides the MUL and ADD from instru
On Tue, May 6, 2014 at 3:53 AM, Juha-Pekka Heikkila
wrote:
> Signed-off-by: Juha-Pekka Heikkila
> ---
> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> b/src/mes
Am 06.05.2014 17:03, schrieb Ilia Mirkin:
> On Tue, May 6, 2014 at 10:48 AM, Roland Scheidegger
> wrote:
>> Looks good to me.
>
> Thanks!
>
>> Does that mean if also the GATHER_SM5 cap is supported you have to
>> support 4 independent, non-constant offsets?
>
> Not 100% sure what you're asking
On Tue, May 6, 2014 at 1:29 PM, Roland Scheidegger wrote:
> Am 06.05.2014 17:03, schrieb Ilia Mirkin:
>> On Tue, May 6, 2014 at 10:48 AM, Roland Scheidegger
>> wrote:
>>> Looks good to me.
>>
>> Thanks!
>>
>>> Does that mean if also the GATHER_SM5 cap is supported you have to
>>> support 4 indep
Hello Jonas,
I tested your program and on my system (Fedora 19) on an Evergreen
(Radeon HD 5850) and I have the same issue indeed.
Here is my result :
Mesa 9.2.4 (from F19 repo) => Data does NOT match up!
Mesa 9.2.5 => Data does NOT match up!
Mesa 10.0.5 => Data does NOT match up!
Mesa 10.1.0 =>
Kenneth Graunke writes:
> Fixes glean/texture_srgb, which hit recursive-flush prevention
> assertions in vbo_exec_FlushVertices.
>
> This probably hurts the performance of front buffer rendering, but
> very few people in their right mind do front buffer rendering.
This series is:
Reviewed-by: E
FWDing to mesa-dev, since they should have the same issue.
- Forwarded message from "Yang, Rong R" -
Date: Tue, 6 May 2014 08:26:15 +
From: "Yang, Rong R"
To: "intel-...@lists.freedesktop.org"
Subject: [Intel-gfx] How user space applications load registers on HSW?
Message-ID:
<759
Nice work.
On Tue, May 6, 2014 at 1:16 AM, Iago Toral Quiroga wrote:
> diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
> b/src/mesa/drivers/dri/i965/brw_shader.cpp
> index 6e74803..37d3eab 100644
> --- a/src/mesa/drivers/dri/i965/brw_shader.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_shader.
On 05/06/2014 08:26:15 AM, Yang, Rong R wrote:
> Hi,
>
> I am developing the HSW’s OCL driver in the linux. I encounter a LRI
> problem on HSW.
>
>
> Some gpgpu's applications, which use the shared local memory, must load
> the L3CTRLREG2 and L3CTRLREG3 registers to allocate the SLM in the L3
>
In order to support the (currently unregistered) Chromium-specific EGL
extension eglGetSyncValuesCHROMIUM on Intel systems, we need to import
the Chromium header that defines it. The file was downloaded from
https://chromium.googlesource.com/chromium/chromium/+/trunk/ui/gl/EGL/eglextchromium.h
I
Chromium defined a new GL extension (that isn't registered with Khronos).
We need to add an EGL extension for it, so we can migrate ChromeOS on
Intel systems to use EGL instead of GLX.
http://git.chromium.org/gitweb/?p=chromium/src/third_party/khronos.git;a=commitdiff;h=27cbfdab35c601f70aa150581ad
---
Noticed by inspection. Not tested.
It looks like this would have messed up the scratch space base pointer.
src/mesa/drivers/dri/i965/gen8_ps_state.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen8_ps_state.c
b/src/mesa/drivers/dri/i96
On 05/06/2014 12:59 PM, Matt Turner wrote:
> ---
> Noticed by inspection. Not tested.
>
> It looks like this would have messed up the scratch space base pointer.
>
> src/mesa/drivers/dri/i965/gen8_ps_state.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa
On Tue, May 6, 2014 at 1:40 PM, Kenneth Graunke wrote:
> NAK. I don't know what docs you're looking at, but the latest ones:
>
> DW0 - header, opcode, length
> DW1, DW2 - kernel start pointer 0
> DW3. has bit 30, "Vector Mask Enable."
Oh, you're right. The 3DSTATE_PS was 404'd this morning, so I
This is the only case where a fs_reg in brw_fs_visitor is used during
optimization/code generation, and it meant that optimizations had to be
careful to not move pixel_x/y's register number without updating it.
Additionally, it turns out we had a couple of other UW values that weren't
getting this
Now that we aren't using pixel_[xy] in live variables, nothing is looking
at these regs after the visitor stage.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 37
1 file changed, 37 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/driver
We only get here if the VS/GS compiled programs change, but we can even
skip it if the VS/GS size didn't change.
Affects cairo runtime on glamor by -1.26471% +/- 0.674335% (n=234)
---
src/mesa/drivers/dri/i965/brw_context.c | 2 +-
src/mesa/drivers/dri/i965/brw_context.h | 5 +++--
src/mesa/dri
Should fix SGE/SSG instructions, which were previously getting integer
0/-1 values.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
b/src/g
This is a port of commit c9c08867ed07ceb10b67ffac5f0a33812710a5e8.
A tiny bit of extra work was necessary to not break stencil texturing.
Cc: "10.2"
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen8_surface_state.c | 28 ++
src/mesa/drivers/dri/i965/intel
This patch is:
Reviewed-by: Chris Forbes
Spotted some other bugs (in using a view as a depth/stencil
attachment) while reading around this, which I'll take care of.
On Wed, May 7, 2014 at 12:03 PM, Kenneth Graunke wrote:
> This is a port of commit c9c08867ed07ceb10b67ffac5f0a33812710a5e8.
> A
I'm using some older hardware - an ATI Radeon 9200 - which can only handle
up to OpenGL 1.2. I was wondering if it's possible to use the hardware
renderer generally and have the driver hand off the handling of functions
which my video card can't handle (such as functions from a higher OpenGL
versio
Hello Benjamin,
thank you very much for testing this. If this issue is fixed in latest
Mesa, then I don't
have to issue a bug report after all. It's also not critical for me to have
this issue fixed
on my distribution as I can easily work around it; I just wanted to make
sure that the
fix for this
On 6 May 2014 14:51, Patrick McMunn wrote:
> I'm using some older hardware - an ATI Radeon 9200 - which can only handle
> up to OpenGL 1.2. I was wondering if it's possible to use the hardware
> renderer generally and have the driver hand off the handling of functions
> which my video card can't h
And do blorp at the same time.
---
src/mesa/drivers/dri/i965/brw_blorp.h | 6 ++
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp| 2 +-
src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp | 10 +++---
src/mesa/drivers/dri/i965/brw_blorp_blit_eu.h | 3 ++-
src/mesa/drivers/dri/i
The docs say that flipping this bit on for shaders that don't do SIMD
branching (i.e., non-uniform control flow) will save us some power.
An easy first step is turning this on when we don't see control flow.
In the future with more infrastructure in place, we can determine if
all branching condit
All of the other control flow instructions are dependent on the
existence of an IF or WHILE instruction.
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 2 ++
src/mesa/drivers/dri/i965/gen8_fs_generator.cpp | 2 ++
2 files changed, 4 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_
---
src/mesa/drivers/dri/i965/gen6_vs_state.c | 3 ++-
src/mesa/drivers/dri/i965/gen7_vs_state.c | 3 ++-
src/mesa/drivers/dri/i965/gen8_vs_state.c | 3 ++-
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen6_vs_state.c
b/src/mesa/drivers/dri/i965/gen6_vs
---
src/mesa/drivers/dri/i965/gen6_wm_state.c | 5 +
src/mesa/drivers/dri/i965/gen7_wm_state.c | 5 +
src/mesa/drivers/dri/i965/gen8_ps_state.c | 5 +
3 files changed, 15 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen6_wm_state.c
b/src/mesa/drivers/dri/i965/gen6_wm_state.c
---
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 1 +
src/mesa/drivers/dri/i965/gen7_blorp.cpp | 1 +
2 files changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
index 4222fa8..5d7be60 100644
--- a/src/mesa/drivers/dri/i965/gen6
All of the other control flow instructions are dependent on the
existence of an IF or WHILE instruction.
---
src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 3 +++
src/mesa/drivers/dri/i965/gen8_vec4_generator.cpp | 3 +++
2 files changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/i96
---
src/mesa/drivers/dri/i965/brw_context.h | 2 ++
src/mesa/drivers/dri/i965/brw_vec4.cpp| 6 --
src/mesa/drivers/dri/i965/brw_vec4.h | 10 ++
src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 7 ---
src/mesa/drivers/dri/i965/brw_vec4_gs_vis
---
src/mesa/drivers/dri/i965/gen7_gs_state.c | 4 +++-
src/mesa/drivers/dri/i965/gen8_gs_state.c | 3 ++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen7_gs_state.c
b/src/mesa/drivers/dri/i965/gen7_gs_state.c
index d18ae15..d7ba4a0 100644
--- a/src/m
On Wed, May 7, 2014 at 9:38 AM, Matt Turner wrote:
> ---
> src/mesa/drivers/dri/i965/gen6_vs_state.c | 3 ++-
> src/mesa/drivers/dri/i965/gen7_vs_state.c | 3 ++-
> src/mesa/drivers/dri/i965/gen8_vs_state.c | 3 ++-
> 3 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/driv
On Tue, May 6, 2014 at 7:14 PM, Chia-I Wu wrote:
> On Wed, May 7, 2014 at 9:38 AM, Matt Turner wrote:
>> ---
>> src/mesa/drivers/dri/i965/gen6_vs_state.c | 3 ++-
>> src/mesa/drivers/dri/i965/gen7_vs_state.c | 3 ++-
>> src/mesa/drivers/dri/i965/gen8_vs_state.c | 3 ++-
>> 3 files changed, 6 ins
On Mon, May 5, 2014 at 5:37 AM, Chia-I Wu wrote:
> On Sat, May 3, 2014 at 1:59 AM, Ian Romanick wrote:
>> On 04/22/2014 01:58 AM, Chia-I Wu wrote:
>>> From: Chia-I Wu
>>>
>>> Threaded glCompileShader can be enabled for a context by calling
>>> _mesa_enable_glsl_threadpool. It will initialize th
53 matches
Mail list logo
