ello All
I am using Mesa-7.10.2 stack.
I am trying to run EGL with egl_gallium state trackers
(GLES=>EGL=>egl_gallium=>fbdev) over fbdev with following configuration
./configure --prefix=/opt/mesa-arm-genoa-new --host=arm-linux
--build=i686-linux --enable-gles2 --with-x=no --with-egl-platfor
As stated in an email sent a week and a half ago, i need 6 "we will be
there nomatter what" speakers for FOSDEM this year before i go and talk
to the FOSDEM organizers.
So far we have:
* Martin Peres - Nouveau
* Alon Levy - Xspice
* Chris Wilson - Cairo
Only half the amount needed, with 5 days l
After going back and forth many times, I think Daniel and I have agreed
on the solution for non-blocking maps.
This new interface adds a new call to map buffers non-blocking if
possible. In actuality it may block, but it will track if the buffer
needs flushing or not and does the right thing for t
Querying a BO's cache level can help clients wishing to map the buffer.
For example, an Ironlake machine could query the buffer to determine it
should use GTT mappings, while a Sandybridge machine running the same
code would prefer to use regular CPU mapped buffers since the cache is
coherent.
Cc:
From: Daniel Vetter
This adds a new mode to map gem objects in a non-blocking way.
The new kernel interface required to get the caching level/coherency
is not yet wired up. All the code to transparently choose between gtt
mappings or (if coherent) cpu mappings is already in place, though.
To ma
Yuanhan recently added tests which check for conformance on the API.
This patch goes on top of his to help make a dent in testing
functionality.
Cc: Yuanhan Liu
Cc: Piglit Devs
Signed-off-by: Ben Widawsky
---
tests/all.tests|1 +
tests/spec/arb_map_buffe
Clean the code up, and always use a BO when creating a new buffer. I've
not seen any regressions but haven't yet tried this on < Gen6.
Cc: Chad Versace
Cc: Eric Anholt
Signed-off-by: Ben Widawsky
---
src/mesa/drivers/dri/intel/intel_buffer_objects.c | 114 ++---
src/mesa/drive
When mapping a range of a buffer that has the UNSYNCHRONIZED_BIT, and is
only writable, we can take some shortcuts and let people shoot their
feet.
Cc: Eric Anholt
Signed-off-by: Ben Widawsky
---
src/mesa/drivers/dri/intel/intel_buffer_objects.c | 34 ++--
src/mesa/drivers/dri
On Sun, Sep 25, 2011 at 2:11 AM, Romain Failliot
wrote:
> Hi all!
>
> I'm an experienced programmer, but I've never touched the mesa code.
> I desperately want to help, but for that, I need a "mentor" to teach me the
> basics about the project, the good practices and eventually drive me through
>
On Fri, Sep 23, 2011 at 10:06:52AM -0700, Eric Anholt wrote:
> On Thu, 15 Sep 2011 16:02:49 +0800, Yuanhan Liu
> wrote:
> > intel_image->mt might be NULL, say with border width set. It then would
> > trigger a segfault at intel_map/unmap_texture_image function.
> >
> > This would fix the oglc mi
On Sun, Sep 25, 2011 at 4:22 PM, Gaetan Nadon wrote:
> If you are moving towards a non-hacked automake world, the INSTALL variable
> should not be used for mesa makefiles. It all depends on the end goals and
> the motivation behind the conversion to automake which has not been
> explained yet.
Pe
This is a follow-up to commit
2d686fe911a89fa477ee3848da41ebfb100500bf, which added decoding of
GL_CLIP_DISTANCE[67] to the _mesa_set_enable() function. This patch
makes the following additional fixes:
- Uses GL_CLIP_DISTANCEi enums consistently within enable.c rather
than the deprecated GL_CLI
On Sun, Sep 25, 2011 at 3:06 PM, Gaetan Nadon wrote:
> I had a quick look, configure.ac is huge and has a big impact on Makefiles.
> I think it should be reviewed and cleaned-up to understand how it affects
> makefiles.
>
> Just a few examples of statements to investigate. Not that they are bad, b
On Sat, Sep 24, 2011 at 9:06 PM, Matt Turner wrote:
> Signed-off-by: Matt Turner
> ---
> The last discussion about using automake ("[RFC] Convert mesa to
> automake/libtool")
> ended without anything happening, probably because the branch wasn't ready.
>
> This patch is an attempt to get the bal
On Sun, Sep 25, 2011 at 7:09 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> This add support for unsigned/signed integer types via adding a 'pure' bit
> in the format description table. It adds 4 new u_format get/put hooks,
> for get/put uint and get/put sint so that accessors can get native acce
From: Dave Airlie
This add support for unsigned/signed integer types via adding a 'pure' bit
in the format description table. It adds 4 new u_format get/put hooks,
for get/put uint and get/put sint so that accessors can get native access
to the integer bits. This is used to avoid precision loss v
On pre-GEN6 chips, the VUE slots set aside for clip distance aren't
actually used, so there is no reason for the clipper to waste time
interpolating them.
When commit 62bad54727690bff5ed42a74272e7822fd36cdb6 changed the enum
value used to represent these VUE slots, that caused the clipper to
start
This patch corrects two errors in the computation of the psiz/flags
VUE slot on pre-GEN5 when using the new VS backend:
- The clip flags (which should be stored in the w component of the
first VUE slot) were being accidentally duplicated in all other
components of that VUE slot, causing partia
This constructor was storing its argument in the wrong field of the
"imm" enum, resulting in it being converted to a float when it should
have remained an unsigned integer. This was preventing clipping from
working properly on pre-GEN6.
---
src/mesa/drivers/dri/i965/brw_vec4.h |2 +-
1 files
In pre-GEN6, when using clip planes, both the vertex shader and the
clipper need access to the client-supplied clip planes, since the
vertex shader needs them to set the clip flags, and the clipper needs
them to determine where to insert new vertices.
With the old VS backend, we used a clever opti
Now that i965 supports 8 clip planes instead of 6, the size of the
brw_vs_compile::userplane array needs to be increased to 8. Changed
the array size to MAX_CLIP_PLANES so that if the number changes again
in the future, this array size won't be missed.
---
src/mesa/drivers/dri/i965/brw_vs.h |
When using user-defined clipping planes, the i965 driver compacts the
array of clipping planes so that disabled clipping planes do not
appear in it--this saves precious push constant space and makes it
easier to generate the pre-GEN6 clip program. As a result, when
enabling clipping planes in GEN6
Since the i965 driver supports 8 clipping planes now, we need 4 bits
to store the number of user clipping planes, not 3.
In theory this isn't strictly necessary, since brw_clip.h is only used
on pre-GEN6, and pre-GEN6 only advertises support for 6 clipping
planes, but it seems wise to err on the s
---
src/mesa/state_tracker/st_draw.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c
index 39a947d..5748020 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -2
On Sun, Sep 25, 2011 at 7:09 AM, Benjamin Bellec wrote:
> Hello,
>
> In src/gallium/drivers/r600/r600_pipe.c I saw this :
>
> /* Render targets. */
> case PIPE_CAP_MAX_RENDER_TARGETS:
> /* FIXME some r6xx are buggy and can only do 4 */
> return 8;
>
> The last line of R6xx_R7
Sorry for the delay, got no internet for nearly a week.
Patch is committed.
Thanks,
Christian.
Am Donnerstag, den 22.09.2011, 21:03 +0200 schrieb Emeric Grange:
> This patch fix a "Unresolved Symbols" run time error when using G3DVL
> through the VDPAU state tracker, by linking the vdpau target
Hello,
In src/gallium/drivers/r600/r600_pipe.c I saw this :
/* Render targets. */
case PIPE_CAP_MAX_RENDER_TARGETS:
/* FIXME some r6xx are buggy and can only do 4 */
return 8;
The last line of R6xx_R7xx_3D.pdf says :
4 MRT + 8-Sample Restriction
On RV610, there is
Hi all!
I'm an experienced programmer, but I've never touched the mesa code.
I desperately want to help, but for that, I need a "mentor" to teach me the
basics about the project, the good practices and eventually drive me through
the bugs and features.
I'd be glad to begin with a simple, but long
28 matches
Mail list logo
