https://bugs.freedesktop.org/show_bug.cgi?id=62647
--- Comment #28 from delacruz raul.delac...@gmail.com ---
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
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
v2:
- fix earlier rebase error breaking bisect
(loaderPriv - loaderPrivate)
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/i965/intel_screen.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
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
---
v2:
- refactor both occurences, not just one
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
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
Otherwise 'intel_set_texture_image_region()' won't have enough
details to work with.
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
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
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
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
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
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
Signed-off-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
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
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
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
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
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
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 computing
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
---
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
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
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 local memory
On 07/10/2013 02:56 PM, Chris Forbes wrote:
Fixes isinf(), isnan() from GLSL 1.30
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
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
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
On Tue, Jul 9, 2013 at 6:44 PM, Chris Forbes chr...@ijw.co.nz 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 =
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
On 9 July 2013 18:12, Anuj Phogat 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 gen7 systems unless we see any
performance regressions. I
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 07/10/2013 11:09 AM, Paul Berry wrote:
On 9 July 2013 18:12, Anuj Phogat anuj.pho...@gmail.com
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
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:
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
The exact text is in the public docs, so we should cite those.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
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
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
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
---
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
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 kenn...@whitecape.org
---
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
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
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
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
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
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
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
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
---
brw_tex_layout.c sets up the align_w/h fields, and has all the
appropriate spec references already.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
I really shouuld go update the
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
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
---
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, and
On 07/08/2013 03:12 PM, Marek Olšák wrote:
On Tue, Jul 2, 2013 at 10:02 PM, Ian Romanick i...@freedesktop.org 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)
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,
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
On 07/09/2013 04:33 PM, Stéphane Marchesin wrote:
On Fri, May 10, 2013 at 11:37 PM, Eric Anholt e...@anholt.net 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
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
On Wed, Jul 10, 2013 at 6:02 PM, Kenneth Graunke kenn...@whitecape.org wrote:
On 07/09/2013 04:33 PM, Stéphane Marchesin wrote:
On Fri, May 10, 2013 at 11:37 PM, Eric Anholt e...@anholt.net wrote:
We keep having to pass the attachments around with our gl_renderbuffers
because that's the only
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 olva...@gmail.com
---
src/glsl/builtin_compiler/Makefile.am | 3 ++-
https://bugs.freedesktop.org/show_bug.cgi?id=66806
--- Comment #1 from Roland Scheidegger srol...@vmware.com ---
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
On Thu, Jul 11, 2013 at 11:05 AM, Stéphane Marchesin
stephane.marche...@gmail.com wrote:
On Wed, Jul 10, 2013 at 6:02 PM, Kenneth Graunke kenn...@whitecape.org
wrote:
On 07/09/2013 04:33 PM, Stéphane Marchesin wrote:
On Fri, May 10, 2013 at 11:37 PM, Eric Anholt e...@anholt.net wrote:
We
On Wed, Jul 10, 2013 at 6:27 PM, Dave Airlie airl...@gmail.com wrote:
On Thu, Jul 11, 2013 at 11:05 AM, Stéphane Marchesin
stephane.marche...@gmail.com wrote:
On Wed, Jul 10, 2013 at 6:02 PM, Kenneth Graunke kenn...@whitecape.org
wrote:
On 07/09/2013 04:33 PM, Stéphane Marchesin wrote:
On
Reviewed-by: Chris Forbes chr...@ijw.co.nz
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Wed, Jul 10, 2013 at 6:14 PM, Chia-I Wu olva...@gmail.com 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
https://bugs.freedesktop.org/show_bug.cgi?id=66558
Björn Beutel bjoern-beu...@arcor.de changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop
54 matches
Mail list logo
