https://bugs.freedesktop.org/show_bug.cgi?id=66809
Priority: medium
Bug ID: 66809
Assignee: mesa-dev@lists.freedesktop.org
Summary: Compiz segfault with latest mesa-git
Severity: major
Classification: Unclassified
OS: Linux (
anyone get a chance to look at this?
On Thu, Jun 20, 2013 at 08:14:33PM +1000, Jonathan Gray wrote:
> Use grep -w instead of the empty string escape sequences
> which are less portable. Makes the grep tests
> function as intended on OpenBSD.
>
> Signed-off-by: Jonathan Gray
> ---
> configure.a
On Wed, Jun 26, 2013 at 09:13:13AM +0200, Christian König wrote:
> Am 26.06.2013 09:10, schrieb Jonathan Gray:
> >Signed-off-by: Jonathan Gray
>
> Looks good on first glance, patch is:
>
> Reviewed-by: Christian König
Can you push it to the repo then?
>
> >---
> > src/gallium/state_trackers
https://bugs.freedesktop.org/show_bug.cgi?id=66558
Björn Beutel changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
On Wed, Jul 10, 2013 at 6:14 PM, Chia-I Wu wrote:
> libglslcore.la and libglcpp.la that are built with builtin_compiler are also
> linked to by drivers not using libdricore. Since there is no public symbol in
> them, it is better to mark all symbols hidden.
>
> Signed-off-by: Chia-I Wu
> ---
>
Reviewed-by: Chris Forbes
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Wed, Jul 10, 2013 at 6:27 PM, Dave Airlie wrote:
> On Thu, Jul 11, 2013 at 11:05 AM, Stéphane Marchesin
> wrote:
>> On Wed, Jul 10, 2013 at 6:02 PM, Kenneth Graunke
>> wrote:
>>> On 07/09/2013 04:33 PM, Stéphane Marchesin wrote:
On Fri, May 10, 2013 at 11:37 PM, Eric Anholt wrote:
On Thu, Jul 11, 2013 at 11:05 AM, Stéphane Marchesin
wrote:
> On Wed, Jul 10, 2013 at 6:02 PM, Kenneth Graunke
> wrote:
>> On 07/09/2013 04:33 PM, Stéphane Marchesin wrote:
>>>
>>> On Fri, May 10, 2013 at 11:37 PM, Eric Anholt wrote:
We keep having to pass the attachments around with
https://bugs.freedesktop.org/show_bug.cgi?id=66806
--- Comment #1 from Roland Scheidegger ---
I can't reproduce this here for some reason.
That said I think we should probably manipulate mxcsr a bit more, in particular
we should explicitly disable all exceptions (they are disabled by default but
libglslcore.la and libglcpp.la that are built with builtin_compiler are also
linked to by drivers not using libdricore. Since there is no public symbol in
them, it is better to mark all symbols hidden.
Signed-off-by: Chia-I Wu
---
src/glsl/builtin_compiler/Makefile.am | 3 ++-
1 file changed, 2
On Wed, Jul 10, 2013 at 6:02 PM, Kenneth Graunke wrote:
> On 07/09/2013 04:33 PM, Stéphane Marchesin wrote:
>>
>> On Fri, May 10, 2013 at 11:37 PM, Eric Anholt wrote:
>>>
>>> We keep having to pass the attachments around with our gl_renderbuffers
>>> because that's the only way to find what the g
Fixes nouveau crash in the following piglit test:
general/attribs GL3
v3: Handle both signed and unsigned ints.
Do not typecast the ints to floats, rather feed the ints directly.
This is what the blob does :)
v2: Convert the attribute(s) to float and submit as such.
Comment about usin
On 07/09/2013 04:33 PM, Stéphane Marchesin wrote:
On Fri, May 10, 2013 at 11:37 PM, Eric Anholt wrote:
We keep having to pass the attachments around with our gl_renderbuffers
because that's the only way to find what the gl_renderbuffer actually
refers to. This is a step toward removing that (t
From: Roland Scheidegger
srgb-to-linear is using 3rd degree polynomial for now which should be _just_
good enough. Reverse is using some rational polynomials and is quite accurate,
though not hooked into llvmpipe's blend code yet and hence unused (untested).
Using a table might also be an option
From: Roland Scheidegger
We had to disable fast rsqrt before because it wasn't precise enough etc.
However in situations when we know we're not going to need more precision
we can still use a fast rsqrt (which can be several times faster than
the quite expensive sqrt). Hence introduce a new helpe
On 07/10/2013 01:22 PM, Anuj Phogat wrote:
From BSpec: 3D-Media-GPGPU Engine > 3D Pipeline > Pixel >
Pixel Backend > MCS Buffer for Render Target(s) [DevIVB+]:
[DevHSW:GT3]: Clear rectangle must be aligned to two times
the number of pixels in the table shown below...
Observed no piglit, gles3con
Just tried this out, on your XA branch, and I'm getting rendering
issues in gnome-terminal. It looks like some text is offset by
one or two lines, and the rest looks a bit like pitch issues.
http://i.imgur.com/mdivF0q.png
I can't really see anything in the patch that would cause this,
going to ta
https://bugs.freedesktop.org/show_bug.cgi?id=66806
Priority: medium
Bug ID: 66806
Keywords: regression
CC: za...@vmware.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: [softpipe] glxgears floating point exception
On 07/09/2013 06:12 PM, Anuj Phogat wrote:
For HSW GT3 clear rectangle must be aligned to two times the number of
pixels in the table shown in Ivy Bridge PRM, Vol2 Part1 11.7.
It should be safe to do this for all gen7 systems unless we see any
performance regressions. I observed no piglit, gles3c
On 07/08/2013 03:12 PM, Marek Olšák wrote:
On Tue, Jul 2, 2013 at 10:02 PM, Ian Romanick wrote:
3. I'd like to make some adjustments to our process for picking patches back
to the stable branch. The current process is okay, but it has some kinks.
The two big (related) problems are people eithe
The Sandybridge code had a citation for the range of the "Maximum Number
of Threads" field, and the Ivybridge code just mentioned the "BSpec" in
general. That's documented in the obvious place, so people can find it
without a spec reference.
The real value of the comment is to say "we tried zero,
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen7_blorp.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
index cfac411..fbdd2be 100644
--- a/src/mesa/drivers/dri/i965/ge
brw_tex_layout.c sets up the align_w/h fields, and has all the
appropriate spec references already.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
I really shouuld go update the comments in brw_tex_l
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen7_blorp.cpp | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
index acd6237..199866e 100644
--- a/src/mesa/drivers/dri/i965/g
Unfortunately, the workaround text never made it into the Sandybridge
PRM, so we still have to refer to the BSpec.
It also wasn't obvious why we needed this workaround at all, since we
don't currently do VS passthrough - but BLORP can turn off the VS.
Signed-off-by: Kenneth Graunke
---
src/mesa
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index ab7a9a3..7f4121c 100644
--- a/src/mesa/driv
Presumably, this comment exists to justify the usage of
I915_GEM_DOMAIN_SAMPLER for this relocation. At one point, this was
necessary to ensure that the right flushing was done to keep caches
coherent. These days, the kernel just flushes everything, so I don't
think it matters.
Still, the commen
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
index 684669b..fe
Sadly, the Ivybridge PRM can't be cited, as it is missing the relevant
text for some reason. However, the Sandybridge PRM has the text Chad
originally quoted, and the modern BSpec has the same text.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen7_misc_state.c | 14 +---
I cut and pasted these comments from the Gen4 code during Ivybridge
enabling, and didn't understand what they meant at the time.
The data cache is NOT the same as the sampler cache on Ivybridge.
The sampler cache has L1 and L2 caches in addition to the L3 cache,
while data port messages to the "da
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_structs.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_structs.h
b/src/mesa/drivers/dri/i965/brw_structs.h
index 6e5a682..e1ba5f8 100644
--- a/src/mesa/drivers/dri/i965/brw
The exact text is in the public docs, so we should cite those.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_eu_emit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index c
The Ivybridge PRM adds new SFIDs and lists them in a different volume
than Sandybridge, so it's worth adding a reference.
I also removed the BSpec reference, as the section it referred to
was moved somewhere, and I couldn't find it. This leaves one Haswell
SFID without a citation, but we can add
>From BSpec: 3D-Media-GPGPU Engine > 3D Pipeline > Pixel >
Pixel Backend > MCS Buffer for Render Target(s) [DevIVB+]:
[DevHSW:GT3]: Clear rectangle must be aligned to two times
the number of pixels in the table shown below...
Observed no piglit, gles3conform regressions with this patch.
Fixes: htt
On 07/10/2013 11:09 AM, Paul Berry wrote:
On 9 July 2013 18:12, Anuj Phogat mailto:anuj.pho...@gmail.com>> wrote:
For HSW GT3 clear rectangle must be aligned to two times the number of
pixels in the table shown in Ivy Bridge PRM, Vol2 Part1 11.7.
It should be safe to do this for all
Please keep your replies on the list so that others can potentially
help/reply.
On 07/10/2013 12:05 PM, Andy Li wrote:
> Hi Brain,
>
> Thank you for your reply.
> You were right, my plan is to use OSMesa and draw into malloc'd frame
> buffer in my device, so I can display the image on the screen
On 9 July 2013 18:12, Anuj Phogat wrote:
> For HSW GT3 clear rectangle must be aligned to two times the number of
> pixels in the table shown in Ivy Bridge PRM, Vol2 Part1 11.7.
> It should be safe to do this for all gen7 systems unless we see any
> performance regressions. I observed no piglit,
I don't quite understand what this should do, at first sight it looks
like a ugly hack (which should really not be part of gallium interface)
to make fast color clearing work better with window framebuffers.
Seems to go against the idea of resources (which are immutable, well not
the contents but t
On Tue, Jul 9, 2013 at 6:44 PM, Chris Forbes wrote:
> I think it would be clearer to do this, rather than 4 parallel checks:
Yes. It's clearer. I will make this change.
>
> if (intel->gen >= 7) {
> /* rationale ... */
> x0 = ROUND_DOWN_TO(x0, 2 * x_align);
> y0 = ROUND_DOWN_TO(y0, 2
On 07/10/2013 02:46 PM, Chris Forbes wrote:
Fixes undefined results if a back color is written, but the
corresponding front color is not, and only backfacing primitives are
drawn. Results are still undefined if a frontfacing primitive is drawn,
but that's OK.
The other reasonable way to fix this
On 07/10/2013 02:56 PM, Chris Forbes wrote:
Fixes isinf(), isnan() from GLSL 1.30
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_vs_state.c | 9 -
src/mesa/drivers/dri/i965/brw_wm_state.c | 10 +-
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git
On Mit, 2013-07-10 at 08:15 -0700, Tom Stellard wrote:
> On Wed, Jul 10, 2013 at 12:32:25PM +0200, Michel Dänzer wrote:
> > On Fre, 2013-06-28 at 14:37 -0700, Tom Stellard wrote:
> > > On Wed, Jun 19, 2013 at 06:28:21PM +0200, Michel Dänzer wrote:
> > > >
> > > > These patches implement enough of
Allocate a CMASK on demand and use it to fast clear single-sample
colorbuffers. Both FBOs and window system colorbuffers are fast
cleared. Expand as needed when colorbuffers are mapped or displayed
on screen.
---
src/gallium/drivers/r600/evergreen_state.c | 11
src/gallium/drivers/r600/r600
---
src/gallium/drivers/r600/evergreen_state.c | 24 +++-
src/gallium/drivers/r600/r600_hw_context.c | 12 +---
src/gallium/drivers/r600/r600_resource.h | 3 +++
src/gallium/drivers/r600/r600_texture.c| 25 -
4 files changed, 55 insertions
This interface is used to expand fast-cleared window system
colorbuffers.
---
src/gallium/include/pipe/p_context.h | 8
src/gallium/state_trackers/dri/common/dri_drawable.c | 4
src/gallium/state_trackers/dri/drm/dri2.c| 8 ++--
3 files changed, 18 ins
On Wed, Jul 10, 2013 at 12:32:25PM +0200, Michel Dänzer wrote:
> On Fre, 2013-06-28 at 14:37 -0700, Tom Stellard wrote:
> > On Wed, Jun 19, 2013 at 06:28:21PM +0200, Michel Dänzer wrote:
> > >
> > > These patches implement enough of local memory support to allow radeonsi
> > > to use that for comp
On 07/09/2013 11:20 PM, Andy Li wrote:
Hello everyone,
I have some questions regarding to OSMesa.
I am currently working on a project which I have to use Mesa on an
embedded system.
My current goal is to port the base functions over to the embedded
system, so that I can draw a line on a provi
On Fre, 2013-06-28 at 14:37 -0700, Tom Stellard wrote:
> On Wed, Jun 19, 2013 at 06:28:21PM +0200, Michel Dänzer wrote:
> >
> > These patches implement enough of local memory support to allow radeonsi
> > to use that for computing derivatives, as suggested by Tom.
> >
> > They also almost allow t
Fixes isinf(), isnan() from GLSL 1.30
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_vs_state.c | 9 -
src/mesa/drivers/dri/i965/brw_wm_state.c | 10 +-
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vs_state.c
b/src
Fixes undefined results if a back color is written, but the
corresponding front color is not, and only backfacing primitives are
drawn. Results are still undefined if a frontfacing primitive is drawn,
but that's OK.
The other reasonable way to fix this would have been to just pick
the one color sl
On Die, 2013-07-09 at 21:21 -0700, Tom Stellard wrote:
>
> diff --git a/src/gallium/docs/source/screen.rst
> b/src/gallium/docs/source/screen.rst
> index 683080c..f062bea 100644
> --- a/src/gallium/docs/source/screen.rst
> +++ b/src/gallium/docs/source/screen.rst
> @@ -168,6 +168,8 @@ The integer
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
src/mesa/drivers/dri/i965/intel_tex_image.c | 6 ++
2 files changed, 7 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
b/src/mesa/drivers/dri/i965/intel_extensions.c
index 1e762e
v2:
- upon success close the given file descriptors
v3:
- use specific entry for dma buffers instead of the basic for
primes, and enable the extension based on the availability
of the hook
v4 (Chad):
- use ARRAY_SIZE
- improve the comment about the number of file descriptors
Memory originating outside mesa stack is meant to be for reading
only. In addition, the restrictions imposed by the image external
extension should apply. For example, users shouldn't be allowed
to generare mip-trees based on these images.
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri
As specified in:
http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
Checking for the valid fourcc values is left for drivers avoiding
dependency to drm header files here.
v2: enforce EGL_NO_CONTEXT
v3: declare the extension as EGL (not GLES)
v4: do not update e
Otherwise 'intel_set_texture_image_region()' won't have enough
details to work with.
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/intel_screen.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_scre
v2:
- do not break ABI, but instead introduce new entry point for
dma buffers and bump up the dri-interface version to eight
v3 (Chad):
- allow the hook to specify an error originating from the
driver. For now only unsupported format is considered. I
thought about rejecting th
v2:
- refactor both occurences, not just one
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/intel_screen.c | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/intel_fbo.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c
b/src/mesa/drivers/dri/i965/intel_fbo.c
index e746cb4..25024fb 100644
--- a/src/mesa/drivers/dri/i965/intel_fbo.c
+++ b/src/mesa
v2:
- fix earlier rebase error breaking bisect
(loaderPriv -> loaderPrivate)
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/intel_screen.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/
The set introduces new target for 'eglCreateImageKHR()' allowing one
to create EGL images out of externally allocated buffers. For now
only natively supported RGB formatted buffers are accepted.
This revision ties the dma-buffer import extension tightly with the
image external extension. One can a
https://bugs.freedesktop.org/show_bug.cgi?id=62647
--- Comment #28 from delacruz ---
Hi guys,
I have just updated my Mesa drivers through edgers ppa for Ubuntu and it works
like a charm!
My Ivy Bridge i7 in 1920x1080 renders Dota2 with a reasonable performance.
I want to thank everybody for th
62 matches
Mail list logo
