https://bugs.freedesktop.org/show_bug.cgi?id=78771
Priority: medium
Bug ID: 78771
Assignee: wayland-b...@lists.freedesktop.org
Summary: egl not works on 10.0.x and 10.1.x with black screen
QA Contact: mesa-dev@lists.freedesktop.org
Sever
'c' is going away. This is also a bit shorter.
Marking the key pointer as const will also deter people from changing
it in these classes, as that's absolutely not OK.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs.h | 2 ++
src/mesa/drivers/dri/i965/brw_fs_ge
runtime_check_aads_emit isn't actually used currently, but I believe
we should be using it on Gen4-5, so I haven't eliminated it.
See https://bugs.freedesktop.org/show_bug.cgi?id=78679 for details.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 2 +-
src/mesa/d
'c' is going away, but we still need a memory context that lives
for the duration of the compile.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_fs.cpp| 12 +++-
src/mesa/drivers/dri/i965/brw_fs.h
'c' is going away. This is also a bit shorter.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 38 ++--
src/mesa/drivers/dri/i965/brw_fs.h | 1 +
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 15 ++-
3 files changed,
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_wm.c | 22 +++---
src/mesa/drivers/dri/i965/brw_wm.h | 5 -
2 files changed, 11 insertions(+), 16 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_wm.c
b/src/mesa/drivers/dri/i965/brw_wm.c
index dfd008e
Instead, just pass the key and prog_data as separate parameters.
This moves it up a level - one step further toward getting rid of it.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp | 7 +--
src/mesa/drivers/dri/i965/brw_blorp_blit_eu.h | 1 -
src/mes
This is actually for gl_SampleMaskIn, which is quite different than
gl_SampleMask. Renaming should help avoid confusion.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 4 ++--
src/mesa/drivers/dri/i965/brw_wm.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-
Previously, the memory context situation was a bit of a mess:
fs_visitor allocated its own memory context, and freed it in the
destructor. However, some data produced by fs_visitor (such as the list
of instructions) needs to live beyond when fs_visitor is "done", so the
caller can pass it to fs_g
Nothing outside of fs_visitor uses it, so we may as well keep it
internal.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 4 ++--
src/mesa/drivers/dri/i965/brw_fs.h| 3 +++
src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 4 ++--
src/mes
With this one use gone, c->last_scratch is now only used inside
fs_visitor. The rest of the driver uses prog_data->total_scratch.
We already compute similar prog_data fields in fs_visitor, so this
seems reasonable.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 4 +++
As far as I can tell, there's no point in allocating an extra register
and generating a MOV---we can just use the copy provided as part of our
thread payload directly. It's already in the right format.
Of course, there are zero Piglit tests for this. We don't actually ship
the extension (GL_ARB_
We throw away the data generated during compilation on the success path,
so we really ought to on the failure path as well. The caller has no
access to it anyway, so it's purely leaked.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_wm.c | 4 +++-
1 file changed, 3 insertions(
'c' is going away. This is also shorter.
Marking the key pointer as const will also deter people from changing
it in fs_visitor, as it's absolutely not OK to modify it there.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 26 ++--
src/mesa/drivers/dri
This data is created by fs_visitor and only used when emitting code,
so keeping it in fs_visitor makes sense. I decided it would be
reasonable to group these all together in a struct, since they're
highly related.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs.cpp |
The if (!allocated_without_spills) block is an obvious spot for this
performance warning message.
In the Vec4 backend, scratch is also used for indirect access of
temporary arrays. The FS backend doesn't implement that yet, but
if it did, this message would be inaccurate, since scratch access
wou
We already have a perfectly good copy of the program key, and nobody is
going to modify it. The only reason we copied it was because the
brw_wm_compile structure embedded the key rather than pointing to it.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_wm.c | 10 --
1
'c' is going away. This is also a bit shorter.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs.h | 2 ++
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 31 +
src/mesa/drivers/dri/i965/gen8_fs_generator.cpp | 19 ---
3 file
The glGetGraphicsResetStatusARB from ARB_robustness extension always returns
GUILTY_CONTEXT_RESET_ARB
and never returns NO_ERROR for guilty context with LOSE_CONTEXT_ON_RESET_ARB
strategy.
This is because Mesa returns GUILTY_CONTEXT_RESET_ARB if batch_active !=0
whereas kernel driver
never reset
Series is
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
https://bugs.freedesktop.org/show_bug.cgi?id=78604
Michel Dänzer changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |xorg-t...@lists.x.org
On 16/05/14 04:11, Michel Dänzer wrote:
> On 16.05.2014 11:33, Emil Velikov wrote:
[snip]
>> One does not need to share code to use the approach :) Although it makes
>> sense
>> more sense if they do.
>
> Just trying to provide some historical context why things are the way
> they are, in case yo
On 16.05.2014 11:33, Emil Velikov wrote:
> On 16/05/14 03:03, Michel Dänzer wrote:
>> On 15.05.2014 21:13, Emil Velikov wrote:
>>
On 15.05.2014 10:58, Marek Olšák wrote:
> Hi everybody,
>
> Some distros seem to care about the size of Mesa, so I came up with
> this little patch.
On 16.05.2014 02:28, Carl Worth wrote:
> Michel Dänzer writes:
>> Carl, this patch fixes a bug in commit
>> 3e817e7e56806d8adb8f16c35136045c29908944; please hold off on backporting
>> that to the 10.1 branch without this fix.
>
> Thanks for the heads-up. Our usual pattern here is to squash both
>
On Thu, May 15, 2014 at 10:42:07PM +0200, Francisco Jerez wrote:
> Tom Stellard writes:
>
> > On Thu, May 15, 2014 at 06:22:11PM +0200, Francisco Jerez wrote:
> >> Bruno Jimenez writes:
> >>
> >> > Hi,
> >> >
> >> > I'm trying to make clover fail in the case that a kernel fails to build.
> >> >
On 16/05/14 03:03, Michel Dänzer wrote:
> On 15.05.2014 21:13, Emil Velikov wrote:
>
>>> On 15.05.2014 10:58, Marek Olšák wrote:
Hi everybody,
Some distros seem to care about the size of Mesa, so I came up with
this little patch.
It puts r600g and radeonsi into r300_d
On 15.05.2014 21:13, Emil Velikov wrote:
>> On 15.05.2014 10:58, Marek Olšák wrote:
>>> Hi everybody,
>>>
>>> Some distros seem to care about the size of Mesa, so I came up with
>>> this little patch.
>>>
>>> It puts r600g and radeonsi into r300_dri.so. The result is one shared
>>> library which c
On 16.05.2014 07:11, Brian Paul wrote:
> We allocate dispatch tables for BeginEnd and OutsideBeginEnd. But
> when we destroy the context we were freeing the BeginEnd and Exec
> tables. If Exec==BeginEnd we did a double-free. This would happen
> if the context was destroyed while inside a glBegin
On 05/15/2014 05:03 PM, srol...@vmware.com wrote:
From: Roland Scheidegger
When we had just one module "gallivm" was an appropriate name. But now we have
modules containing all functions for a particular variant, so give it a
corresponding name (this is really just for helping debugging).
---
Looping over the instructions and calling brw_disasm doesn't handle
compacted instructions. In most cases, this hasn't been a problem since
we don't compact prior to Sandybridge.
However, Sandybridge's transform feedback GS program should already be
compacted, and so this ought to fix decoding of
We're going to use "disassemble" for the function that disassembles
the whole program.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_context.h | 3 ++-
src/mesa/drivers/dri/i965/brw_disasm.c | 4 +++-
src/mesa/drivers/dri/i965/brw_eu.c | 2 +-
src/mesa/dri
"Disassemble" is an accurate description of what this function does.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_clip.c | 2 +-
src/mesa/drivers/dri/i965/brw_eu.c| 3 ++-
src/mesa/drivers/
dump_prog_cache has interpreted compacted instructions as full size
instructions, decoding garbage and complaining about invalid values.
We can just use brw_dump_compile to handle this correctly in less code.
The output format changes slightly, but it's still perfectly acceptable.
Signed-off-by:
From: Roland Scheidegger
When we had just one module "gallivm" was an appropriate name. But now we have
modules containing all functions for a particular variant, so give it a
corresponding name (this is really just for helping debugging).
---
src/gallium/auxiliary/draw/draw_llvm.c| 16 +
From: Roland Scheidegger
Enabled with GALLIVM_DEBUG=perf (which up to now was only used to print
warnings for unoptimized code).
While some unexpectedly long shader compile times for some shaders were fixed
with 8a9f5ecdb116d0449d63f7b94efbfa8b205d826f this should help recognize such
problems in
We allocate dispatch tables for BeginEnd and OutsideBeginEnd. But
when we destroy the context we were freeing the BeginEnd and Exec
tables. If Exec==BeginEnd we did a double-free. This would happen
if the context was destroyed while inside a glBegin/End pair. Now
free the BeginEnd and OutsideBe
On Thu, 2014-05-15 at 22:42 +0200, Francisco Jerez wrote:
> Tom Stellard writes:
>
> > On Thu, May 15, 2014 at 06:22:11PM +0200, Francisco Jerez wrote:
> >> Bruno Jimenez writes:
> >>
> >> > Hi,
> >> >
> >> > I'm trying to make clover fail in the case that a kernel fails to build.
> >> > My fir
Tom Stellard writes:
> On Thu, May 15, 2014 at 06:22:11PM +0200, Francisco Jerez wrote:
>> Bruno Jimenez writes:
>>
>> > Hi,
>> >
>> > I'm trying to make clover fail in the case that a kernel fails to build.
>> > My first attempt has been to track a llvm compile failure up from
>> > 'radeon_llv
On Thu, May 15, 2014 at 06:22:11PM +0200, Francisco Jerez wrote:
> Bruno Jimenez writes:
>
> > Hi,
> >
> > I'm trying to make clover fail in the case that a kernel fails to build.
> > My first attempt has been to track a llvm compile failure up from
> > 'radeon_llvm_compile' (at radeon/radeon_llv
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Bug 77449 depends on bug 77207, which changed state.
Bug 77207 Summary: [ivb/hsw] batch overwritten with garbage
https://bugs.freedesktop.org/show_bug.cgi?id=77207
What|Removed |Added
--
Michel Dänzer writes:
> Carl, this patch fixes a bug in commit
> 3e817e7e56806d8adb8f16c35136045c29908944; please hold off on backporting
> that to the 10.1 branch without this fix.
Thanks for the heads-up. Our usual pattern here is to squash both
commits into a single commit on the stable branch
On Wed, May 7, 2014 at 4:18 AM, Kevin Rogovin wrote:
> Add support for GLES2 extensions 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).
The patch basically looks good. W
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Bug 77449 depends on bug 77207, which changed state.
Bug 77207 Summary: [ivb/hsw] batch overwritten with garbage
https://bugs.freedesktop.org/show_bug.cgi?id=77207
What|Removed |Added
--
https://bugs.freedesktop.org/show_bug.cgi?id=67672
--- Comment #21 from Paolo Pedroni ---
Still failing on mesa-10.1.3 + llvm-3.4, though my error is slightly different:
FAIL: lp_test_arit
==
rcp(5.877e-39): ref = 1.70068035e+38, out = inf, precision = -inf bits,
FAIL
rsqrt(
Bruno Jimenez writes:
> Hi,
>
> I'm trying to make clover fail in the case that a kernel fails to build.
> My first attempt has been to track a llvm compile failure up from
> 'radeon_llvm_compile' (at radeon/radeon_llvm_emit.c), through
> 'r600_llvm_compile' (at r600/r600_llvm.c) and through
> 'e
On 05/10/2014 08:37 AM, Emil Velikov wrote:
> Reviewed-by: Emil Velikov
> FWIW unless someone has further feedback I'll push this ~mid of the upcoming
> week.
Excellent, thanks!
-Brad
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://li
- Original Message -
> From: Roland Scheidegger
>
> This workaround doesn't list any llvm version, but it was introduced
> 2010-06-10 (e277d5c1f6b2c5a6d202561e67d2b6821a69ecc4). It is unlikely
> this bug is still present in llvm versions we support (3.1+).
> There's no specific test lis
From: Roland Scheidegger
This workaround doesn't list any llvm version, but it was introduced
2010-06-10 (e277d5c1f6b2c5a6d202561e67d2b6821a69ecc4). It is unlikely
this bug is still present in llvm versions we support (3.1+).
There's no specific test listed, but I ran lp_test_arit (which uses
the
From: Roland Scheidegger
32bit code generation and llvm >= 2.7 used a different optimization pass
order - this code was initially introduced (2010-07-23) by
815e79e72c1f4aa849c0ee6103621685b678bc9d, apparently due to buggy code being
generated with then brand new llvm versions (which was llvm 2.7
Yeah, hardlinks might be needed to keep old libGL working.
Marek
On Thu, May 15, 2014 at 2:13 PM, Emil Velikov wrote:
> On 15/05/14 03:33, Michel Dänzer wrote:
>> On 15.05.2014 10:58, Marek Olšák wrote:
>>> Hi everybody,
>>>
>>> Some distros seem to care about the size of Mesa, so I came up with
Am 15.05.2014 14:25, schrieb Jose Fonseca:
> - Original Message -
>> Module: Mesa Branch: master Commit:
>> 3e817e7e56806d8adb8f16c35136045c29908944 URL:
>> https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/mesa/mesa/commit/?id%3D3e817e7e56806d8adb8f16c35136045c2990894
Am 15.05.2014 05:56, schrieb Michel Dänzer:
> From: Michel Dänzer
>
> Fixes the valgrind report below and random crashes with piglit on radeonsi.
>
> ==30005== Conditional jump or move depends on uninitialised value(s)
> ==30005==at 0xB13584E: st_translate_program (st_glsl_to_tgsi.cpp:5100)
On 05/14/2014 06:28 PM, Kenneth Graunke wrote:
Hi all,
Here's a series of patches which implements warnings related to re-linking
shader programs:
1. If you draw with a shader that needs re-linking, it gives you a warning.
Most likely you simply forgot, and will be surprised by the results.
Am 15.05.2014 14:13, schrieb Emil Velikov:
On 15/05/14 03:33, Michel Dänzer wrote:
On 15.05.2014 10:58, Marek Olšák wrote:
Hi everybody,
Some distros seem to care about the size of Mesa, so I came up with
this little patch.
It puts r600g and radeonsi into r300_dri.so. The result is one shared
On 05/14/2014 09:56 PM, Michel Dänzer wrote:
From: Michel Dänzer
Fixes the valgrind report below and random crashes with piglit on radeonsi.
==30005== Conditional jump or move depends on uninitialised value(s)
==30005==at 0xB13584E: st_translate_program (st_glsl_to_tgsi.cpp:5100)
==30005==
- Original Message -
> Module: Mesa
> Branch: master
> Commit: 3e817e7e56806d8adb8f16c35136045c29908944
> URL:
> https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/mesa/mesa/commit/?id%3D3e817e7e56806d8adb8f16c35136045c29908944&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9u
On 15/05/14 03:33, Michel Dänzer wrote:
> On 15.05.2014 10:58, Marek Olšák wrote:
>> Hi everybody,
>>
>> Some distros seem to care about the size of Mesa, so I came up with
>> this little patch.
>>
>> It puts r600g and radeonsi into r300_dri.so. The result is one shared
>> library which contains al
Hi,
I'm trying to make clover fail in the case that a kernel fails to build.
My first attempt has been to track a llvm compile failure up from
'radeon_llvm_compile' (at radeon/radeon_llvm_emit.c), through
'r600_llvm_compile' (at r600/r600_llvm.c) and through
'evergreen_launch_grid' (at r600/evergr
Reviewed-by: Petri Latvala
On 05/14/2014 08:56 PM, Juha-Pekka Heikkila wrote:
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/main/performance_monitor.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/mesa/main/performance_monitor.c
b/src/mesa/main/performance_monitor.c
index
On 05/15/2014 01:22 AM, Pohjolainen, Topi wrote:
> On Thu, May 15, 2014 at 12:57:42AM -0700, Kenneth Graunke wrote:
>> On 05/12/2014 08:42 AM, Topi Pohjolainen wrote:
>>> v2: Create the intel renderbuffer with level hardcoded to zero instead
>>> of overriding it in the surface state configurati
https://bugs.freedesktop.org/show_bug.cgi?id=78716
--- Comment #7 from Michel Dänzer ---
(In reply to comment #5)
> sad to see this bug closed hope still you reopen bug for reasons said below..
If you hit an actual bug in Mesa, file a report describing that bug with all
the necessary information
https://bugs.freedesktop.org/show_bug.cgi?id=78716
--- Comment #6 from Tapani Pälli ---
(In reply to comment #5)
> Hi Tapani and Michel,
8<
> If you don't reopen this bug can I reopen other with a apitrace trace of the
> demo avoiding this queries?
If you have apitrace capture and it shows a bug
On Thu, May 15, 2014 at 12:57:42AM -0700, Kenneth Graunke wrote:
> On 05/12/2014 08:42 AM, Topi Pohjolainen wrote:
> > v2: Create the intel renderbuffer with level hardcoded to zero instead
> > of overriding it in the surface state configuration. Also moved the
> > dimension adjustments for
On Thu, May 15, 2014 at 01:02:38AM -0700, Kenneth Graunke wrote:
> On 05/12/2014 08:42 AM, Topi Pohjolainen wrote:
> > v2: Configure stencil directly for final dimensions instead of
> > adjusting bit by bit for tiling, mip level and msaa.
> >
> > Cc: "10.2"
> > Signed-off-by: Topi Pohjolainen
On 05/12/2014 08:42 AM, Topi Pohjolainen wrote:
> v2: Configure stencil directly for final dimensions instead of
> adjusting bit by bit for tiling, mip level and msaa.
>
> Cc: "10.2"
> Signed-off-by: Topi Pohjolainen
> Reviewed-by: Kenneth Graunke (v1)
> ---
> src/mesa/drivers/dri/i965/brw
On 05/12/2014 08:42 AM, Topi Pohjolainen wrote:
> v2: Create the intel renderbuffer with level hardcoded to zero instead
> of overriding it in the surface state configuration. Also moved the
> dimension adjustments for tiling, mip level, msaa into the render
> buffer creation. Finally p
66 matches
Mail list logo
