https://bugs.freedesktop.org/show_bug.cgi?id=53199
Bug #: 53199
Summary: out-of-bounds read
src/gallium/drivers/softpipe/sp_flush.c:59
Classification: Unclassified
Product: Mesa
Version: unspecified
Platform: All
Fixes same on both sides defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/gallium/auxiliary/translate/translate_generic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/translate/translate_generic.c
b/src/gallium/auxiliary/translate/trans
Marek Olšák wrote:
Does the attached patch fix this issue?
Not properly - it fixes the invalid command stream but the output is not
quite right -
http://www.andyqos.ukfsn.org/vdpau-422-patched.png
Marek
On Mon, Aug 6, 2012 at 5:40 PM, Andy Furniss wrote:
Kernel is dcn card is rv790 -
Good catch.
Reviewed-by: Jose Fonseca
- Original Message -
> Fixes same on both sides defect reported by Coverity.
>
> Signed-off-by: Vinson Lee
> ---
> src/gallium/auxiliary/translate/translate_generic.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/ga
2012/8/6 Laurent Carlier :
> Le lundi 6 août 2012 17:14:52 Alex Deucher a écrit :
>
>> On Mon, Aug 6, 2012 at 5:14 PM, Alex Deucher
>> wrote:
>
>> > On Mon, Aug 6, 2012 at 12:43 AM, Benoit Jacob
>> > wrote:
>
>> >> Hi,
>
>> >>
>
>> >> Just so you know: the WebGL 1.0.1 tests are now passing on 2 d
https://bugs.freedesktop.org/show_bug.cgi?id=53199
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On 08/06/2012 10:38 PM, Dave Airlie wrote:
http://tinderbox.x.org/builds/2012-08-06-0020/logs/libGL/#build
Making all in glx
gmake[4]: Entering directory `/home/tinderbox/mesa/mesa/src/egl/drivers/glx'
CC egl_glx.lo
In file included from ../../../../src/egl/main/egltypedefs.h:37,
pipe_loader_drm_probe_fd only exists if HAVE_PIPE_LOADER_DRM is defined.
This addresses https://bugs.freedesktop.org/show_bug.cgi?id=52962
---
src/gallium/targets/gbm/gbm.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/gallium/targets/gbm/gbm.c b/src/gallium/targets
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/06/2012 07:33 PM, Eric Anholt wrote:
> Chad Versace writes:
>
>> If either argument to driConcatConfigs(a, b) is null or the empty list,
>> then simply return the other argument as the resultant list.
>>
>> All callers were accomplishing that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/06/2012 07:40 PM, Eric Anholt wrote:
> Chad Versace writes:
>
>> This function felt sloppy, so this patch cleans it up a little bit.
>>
>> - Rename `color` to `i`. It is not a color value, only an iterator int.
>
> I'm meh on this change.
A
2012/8/6 Kenneth Graunke :
> On 08/06/2012 02:50 PM, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> Signed-off-by: Paulo Zanoni
>
> Reviewed-by: Kenneth Graunke
>
> Do you have push access? If not, I can commit this for you.
I just discovered I have. Patch committed, thanks.
--
Paulo Zanon
On 08/06/2012 07:32 PM, Eric Anholt wrote:
> Chad Versace writes:
>
>> Add two new functions: intel_miptree_{map,unmap}_multisample, to which
>> intel_miptree_{map,unmap} dispatch. Only mapping flat, renderbuffer-like
>> miptrees are supported.
>>
>> v2:
>> - Move the introduction of
>>
On 08/06/2012 07:49 PM, Eric Anholt wrote:
> Chad Versace writes:
>> + /* Generate multisample configs.
>> +*
>> +* This loop breaks early, and hence is a no-op, on gen < 6.
>> +*
>> +* Multisample configs must follow the singlesample configs in order to
>> +* work around an
Chad Versace writes:
> On 08/06/2012 07:49 PM, Eric Anholt wrote:
>> Chad Versace writes:
>>> + /* Generate multisample configs.
>>> +*
>>> +* This loop breaks early, and hence is a no-op, on gen < 6.
>>> +*
>>> +* Multisample configs must follow the singlesample configs in ord
Anuj Phogat writes:
> Render Target Write message should include source zero alpha value when
> sample-alpha-to-coverage is enabled for an FBO with multiple render targets.
> Source zero alpha value is used as fragment coverage for all the render
> targets.
> diff --git a/src/mesa/drivers/dri/i
I want to introduce some more debug output for performance surprises that
includes fallbacks, but aren't necessarily software rasterization. Leave
INTEL_DEBUG=fall in place for those that have used that flag before.
---
src/mesa/drivers/dri/i915/i915_program.c|2 +-
src/mesa/drivers/dri/i
---
src/mesa/drivers/dri/i965/brw_fs.cpp |5 -
src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp |3 ++-
src/mesa/drivers/dri/intel/intel_context.h|5 +
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/
One of Valve's requests was for GL_ARB_debug_output for performance traps they
should know about. Unfortunately, Mesa's ARB_debug_output support is very
limited at the moment, so this just gets messages in place, which we can
convert to GL_ARB_debug_output at some later time.
---
src/mesa/drivers/dri/i965/brw_vs.c |4
src/mesa/drivers/dri/i965/brw_wm.c |4
2 files changed, 8 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_vs.c
b/src/mesa/drivers/dri/i965/brw_vs.c
index b1b073e..5120167 100644
--- a/src/mesa/drivers/dri/i965/brw_vs.c
+++ b/s
---
src/mesa/drivers/dri/i965/brw_queryobj.c |6 ++
src/mesa/drivers/dri/intel/intel_buffer_objects.c |8 +++-
src/mesa/drivers/dri/intel/intel_regions.c|6 ++
3 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_quer
---
src/mesa/drivers/dri/i965/brw_context.h |2 +
src/mesa/drivers/dri/i965/brw_fs.cpp|6 ++
src/mesa/drivers/dri/i965/brw_program.h |2 +
src/mesa/drivers/dri/i965/brw_vec4_emit.cpp |6 ++
src/mesa/drivers/dri/i965/brw_wm.c | 84 +
---
src/mesa/drivers/dri/i965/brw_clear.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_clear.c
b/src/mesa/drivers/dri/i965/brw_clear.c
index 31c2e45..71d7c48 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/
---
src/mesa/drivers/dri/i965/brw_fs.cpp| 13 +
src/mesa/drivers/dri/i965/brw_vec4_emit.cpp | 20 ++--
src/mesa/drivers/dri/intel/intel_screen.c | 13 +
src/mesa/drivers/dri/intel/intel_screen.h |1 +
4 files changed, 45 insertions(+),
---
src/mesa/drivers/dri/i965/brw_state_cache.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_state_cache.c
b/src/mesa/drivers/dri/i965/brw_state_cache.c
index 4ae8e12..57a5ee9 100644
--- a/src/mesa/drivers/dri/i965/brw_state_cache.c
+++
On Tue, 2012-08-07 at 11:04 -0700, Eric Anholt wrote:
> diff --git a/src/mesa/drivers/dri/intel/intel_context.h
> b/src/mesa/drivers/dri/intel/intel_context.h
> index 6d1a81c..c4efa54 100644
> --- a/src/mesa/drivers/dri/intel/intel_context.h
> +++ b/src/mesa/drivers/dri/intel/intel_context.h
> @@
On 08/06/2012 07:00 PM, Eric Anholt wrote:
> v2: Reduce the impenetrable code in emit_ubo_loads() by 23 lines by keeping
> the ir_variable as the variable part of the offset from handle_rvalue(),
> and track the constant offsets from that with a plain old integer value,
> avoiding a bun
I happened to notice this while looking at a blit pass in l4d2, which had an
optional push/pop around framebuffer srgb setting. It didn't matter in the
end, but the fix is sitting in my tree now.
---
src/mesa/main/attrib.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/m
https://bugs.freedesktop.org/show_bug.cgi?id=53226
Bug #: 53226
Summary: mesa/demos does not build with mesa git because of gbm
API changes
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
https://bugs.freedesktop.org/show_bug.cgi?id=53226
--- Comment #1 from Olivier Blin 2012-08-07 21:14:27
UTC ---
Created attachment 65255
--> https://bugs.freedesktop.org/attachment.cgi?id=65255
eglkms: adapt to gbm stride API change
This patch fixes build with mesa git.
--
Configure bugmail
Do you have any idea what could be wrong with the patch? Also could
please tell me how to setup VDPAU and where to download the tests, so
that I can test this.
Marek
On Tue, Aug 7, 2012 at 11:25 AM, Andy Furniss wrote:
> Marek Olšák wrote:
>>
>> Does the attached patch fix this issue?
>
>
> Not
https://bugs.freedesktop.org/show_bug.cgi?id=51749
--- Comment #1 from Matt Turner 2012-08-07 21:49:33 UTC ---
Not a problem now, right?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the b
On Tue, Aug 7, 2012 at 5:43 PM, Marek Olšák wrote:
> Do you have any idea what could be wrong with the patch? Also could
> please tell me how to setup VDPAU and where to download the tests, so
> that I can test this.
Just add:
--enable-vdpau
to your mesa configure line to enable it. To test it,
On 08/07/2012 03:05 PM, Eric Anholt wrote:
I happened to notice this while looking at a blit pass in l4d2, which had an
optional push/pop around framebuffer srgb setting. It didn't matter in the
end, but the fix is sitting in my tree now.
---
src/mesa/main/attrib.c | 13 +
1 fil
Marek Olšák wrote:
Do you have any idea what could be wrong with the patch? Also could
please tell me how to setup VDPAU and where to download the tests, so
that I can test this.
I don't know about the patch.
One thing which may be a clue or a red herring is that when Christian
first implemen
Here's v3 of Daniel's PIPE_CONTROL series. I reworked it substantially,
moving the length change to the beginning and splitting up the patches
into smaller ones that only do one thing at a time, to make it easier to
bisect or revert if there are any issues. (I'm pretty paranoid when it
comes to P
PIPE_CONTROL has variable length, depending upon generation and whether
we want to do 32-bit or 64-bit data writes. Make it explicit, rather
than hiding a length of 4 in the #define for _3DSTATE_PIPE_CONTROL.
Generated by s/3DSTATE_PIPE_CONTROL/3DSTATE_PIPE_CONTROL | (4 - 2)/g.
This is equivalent
This consolidates the complexity in one place, which is important
because it's about to get even more complicated.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_queryobj.c | 80
1 file changed, 30 insertions(+), 50 deletions(-)
Eric wanted a h
The hardware seems to use the length of the PIPE_CONTROL command to
indicate whether the write is 64-bits or 32-bits. Which makes sense
for immediate writes.
Daniel discovered this by writing a pattern into the query object bo
and noticing that the high 32-bits were left intact, even on those
pip
This implements one of the Sandybridge PIPE_CONTROL workarounds. It
doesn't appear to be required for Ivybridge.
Signed-off-by: Kenneth Graunke
Signed-off-by: Daniel Vetter
---
src/mesa/drivers/dri/i965/brw_queryobj.c | 14 ++
1 file changed, 14 insertions(+)
Unlike Daniel's serie
This consolidates the complexity in one place, which is important
because it's about to get even more complicated.
Signed-off-by: Kenneth Graunke
Signed-off-by: Daniel Vetter
---
src/mesa/drivers/dri/i965/brw_queryobj.c | 111 ---
1 file changed, 43 insertions(+), 68
The hardware seems to use the length of the PIPE_CONTROL command to
indicate whether the write is 64-bits or 32-bits. Which makes sense
for immediate writes.
Daniel discovered this by writing a pattern into the query object bo
and noticing that the high 32-bits were left intact, even on those
pip
Separate out the depth stall from the depth count write. Workarounds
say that a depth stall needs to be preceeded with a non-zero post-sync
op (in this case, the depth count write). Also, before the non-zero
post-sync op, we need a CS stall, which needs a stall at scoreboard.
Signed-off-by: Dani
42 matches
Mail list logo
