Hi,
On Thursday, December 01, 2011 17:53:45 Simon Farnsworth wrote:
> It's unclear exactly what the alignment requirements are for Radeon tiled
> surfaces, but they differ between the DDX and Mesa. Make Mesa match the
> DDX.
>
> Signed-off-by: Simon Farnsworth
> ---
> This basically copies acro
On 5 December 2011 18:42, Eric Anholt wrote:
> On Mon, 5 Dec 2011 15:14:13 -0800, Paul Berry
> wrote:
> > On 5 December 2011 14:53, Eric Anholt wrote:
> >
> > > On Mon, 5 Dec 2011 09:40:45 -0800, Paul Berry <
> stereotype...@gmail.com>
> > > wrote:
> > > > Previously, the geometry shader progr
---
src/mesa/swrast/s_copypix.c | 10 +-
src/mesa/swrast/s_zoom.c| 10 +-
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/src/mesa/swrast/s_copypix.c b/src/mesa/swrast/s_copypix.c
index 3ba31f2..3bdf48b 100644
--- a/src/mesa/swrast/s_copypix.c
+++ b/src/mesa
---
src/mesa/main/readpix.c | 23 ++-
1 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index a7b7ed7..38b9c64 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/readpix.c
@@ -252,10 +252,7 @@ slow_read_rgb
---
src/mesa/main/image.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/image.c b/src/mesa/main/image.c
index b266e26..f29b566 100644
--- a/src/mesa/main/image.c
+++ b/src/mesa/main/image.c
@@ -1520,9 +1520,13 @@ _mesa_convert_colors(GLenum srcType,
In a few places we need to allocate space for some number of generic
pixels. Use this new define instead of a magic number like 16 or
4 * sizeof(GLuint).
---
src/mesa/main/formats.c |2 ++
src/mesa/main/formats.h |8
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a
---
src/mesa/drivers/common/driverfuncs.c |7 +++--
src/mesa/drivers/dri/intel/intel_screen.c | 15 +++--
src/mesa/drivers/dri/intel/intel_span.c | 27 +
src/mesa/drivers/dri/nouveau/nouveau_screen.c |7 +++--
src/mesa/drivers/dri/radeo
---
src/mesa/SConscript |1 +
src/mesa/sources.mak |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/mesa/SConscript b/src/mesa/SConscript
index 633cb9c..da4d9b1 100644
--- a/src/mesa/SConscript
+++ b/src/mesa/SConscript
@@ -170,6 +170,7 @@ swrast_sources = [
'
We'll use the functions that live in main/
Plus, rename the remaining functions with "swrast_" prefix.
---
src/mesa/swrast/s_renderbuffer.c | 242 -
src/mesa/swrast/s_renderbuffer.h | 74
2 files changed, 49 insertions(+), 267 deletions(-)
diff
Implemented in terms of renderbuffer mapping/unmapping and format
packing/unpacking functions.
The swrast and state tracker code for implementing accumulation are
unused and will be removed in the next commit.
v2: don't use memcpy() in _mesa_clear_accum_buffer()
v3: don't allocate MAX_WIDTH array
On Fri, Dec 02, 2011 at 11:25:55AM -0800, Eric Anholt wrote:
> On Thu, 1 Dec 2011 18:26:50 +0800, Yuanhan Liu
> wrote:
> >
> > Actually the first 5 patches are all prepare work for patch 6.
> >
> > I checked those patches will all intel oglc testcases, and found no
> > regressions.
> > What's
On Mon, 5 Dec 2011 15:14:13 -0800, Paul Berry wrote:
> On 5 December 2011 14:53, Eric Anholt wrote:
>
> > On Mon, 5 Dec 2011 09:40:45 -0800, Paul Berry
> > wrote:
> > > Previously, the geometry shader program key was storing all the
> > > information necessary to compute the exact structure of
On Mon, 5 Dec 2011 17:06:00 +0100, Vincent Lejeune wrote:
Nice start! I love that this just takes a chunk of the spec and tests
it. Just a few little comments.
One is that the all.tests line to get your new testcase executed is
missing. Since this test doesn't do any drawing, it should be a
On Sun, 4 Dec 2011 20:38:27 -0700, Brian Paul wrote:
> Most of main/renderbuffer.c was for allocating and accessing software-
> based renderbuffers. That code is only used for software rendering so
> move it to swrast.
>
> The code isn't used at this point yet. The next patch does the switch-o
On Sun, 4 Dec 2011 20:38:26 -0700, Brian Paul wrote:
> ---
> src/mesa/main/depthstencil.c | 155
> --
> src/mesa/main/depthstencil.h | 16
> 2 files changed, 0 insertions(+), 171 deletions(-)
These first two are Reviewed-by: Eric Anholt
pgpTy4
On 5 December 2011 14:53, Eric Anholt wrote:
> On Mon, 5 Dec 2011 09:40:45 -0800, Paul Berry
> wrote:
> > Previously, the geometry shader program key was storing all the
> > information necessary to compute the exact structure of the VUE map
> > (attrs and userclip_active). However, the GS pro
On Mon, 5 Dec 2011 11:21:21 -0800 (PST), airl...@kemper.freedesktop.org (Dave
Airlie) wrote:
> Module: Mesa
> Branch: master
> Commit: 4ed8a585840865550bb9acac38c5ef26670a1fb8
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=4ed8a585840865550bb9acac38c5ef26670a1fb8
>
> Author: Dave
On Mon, 5 Dec 2011 09:40:50 -0800, Paul Berry wrote:
> From: Kenneth Graunke
>
> The 50/50 split is just an attempt to get things working. We likely
> want to tune this, and probably want to avoid allocating the GS any
> space if we're not using it.
>
> For now, this is good enough.
>
> Sign
On Mon, 5 Dec 2011 09:40:45 -0800, Paul Berry wrote:
> Previously, the geometry shader program key was storing all the
> information necessary to compute the exact structure of the VUE map
> (attrs and userclip_active). However, the GS program doesn't depend
> on the exact structure of the VUE m
On Mon, 5 Dec 2011 09:40:44 -0800, Paul Berry wrote:
> This patch adds a new bit to the ctx->NewState bitfield,
> _NEW_TRANSFORM_FEEDBACK, to track state changes that affect
> ctx->TransformFeedback. This bit can be used by driver back-ends to
> avoid expensive recomputations when transform feed
On Mon, 05 Dec 2011 15:21:57 +0100, Thomas Hellstrom
wrote:
> Hi!
>
> Currently the DRI state tracker sends the bits per pixel (bpp) value in
> the format member of a
> getbufferswithformat request, and assumes it can reinterpret the format
> of the returned buffer to something else
> with an
On 5 December 2011 11:54, Kenneth Graunke wrote:
> On 12/05/2011 09:40 AM, Paul Berry wrote:
> > Normally when outputting instructions in SPF (single program flow)
> > mode, we convert IF and ELSE instructions to conditional ADD
> > instructions applied to the IP register, since this lets us avoi
2011/12/5 Michael Karcher :
> Am Montag, den 05.12.2011, 13:03 -0800 schrieb Stéphane Marchesin:
>> > This translation is correct. The mentioned optimization now kicks in
>> > corrrectly removing line 9, but it also reokaces line 6/7 by
>> > 6: R[1].xyz = MUL R[0], T_DIFFUSE
>> > This does yield t
Am Montag, den 05.12.2011, 13:03 -0800 schrieb Stéphane Marchesin:
> > This translation is correct. The mentioned optimization now kicks in
> > corrrectly removing line 9, but it also reokaces line 6/7 by
> > 6: R[1].xyz = MUL R[0], T_DIFFUSE
> > This does yield the correct result in R[1].xyz, but
On Mon, Dec 5, 2011 at 14:00, Michael Karcher
wrote:
> Hello developers,
>
> trying some sample programs on the i915 gallium based driver, I stumbled
> upon getting black/white rendering in teapot, if using the hardware
> pixel shader backend, but getting correct output (yellow textured base)
> wi
Hello developers,
trying some sample programs on the i915 gallium based driver, I stumbled
upon getting black/white rendering in teapot, if using the hardware
pixel shader backend, but getting correct output (yellow textured base)
with software rendering. It turned out that
i915_fpc_optimize_usele
On 12/05/2011 09:40 AM, Paul Berry wrote:
> Normally when outputting instructions in SPF (single program flow)
> mode, we convert IF and ELSE instructions to conditional ADD
> instructions applied to the IP register, since this lets us avoid
> having to emit an ENDIF instruction (and, in Gen4, lets
Now that all RBs have miptrees, and miptree mapping covered these last
two code paths, consistently use them.
---
src/mesa/drivers/dri/intel/intel_fbo.c | 219 +++-
src/mesa/drivers/dri/intel/intel_fbo.h |4 -
2 files changed, 21 insertions(+), 202 deletions(-)
di
This evolved over several commits, and I also wanted to document some
new information about how we handle formats.
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.h | 24 ++--
1 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_mi
This gets the same performance win as the miptree maps did, and
removes a pile of code duplication.
---
src/mesa/drivers/dri/intel/intel_fbo.c | 140 +---
1 files changed, 2 insertions(+), 138 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mes
This mimics the MapRenderbuffer code, and should improve the
performance of glGetTexImage().
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 83
src/mesa/drivers/dri/intel/intel_mipmap_tree.h |2 +
2 files changed, 85 insertions(+), 0 deletions(-)
diff --git a/
We don't gripe about void * arithmetic for our driver, and this
prevents silly casting when assigning the result of mapping to
non-byte types.
---
src/mesa/drivers/dri/intel/intel_regions.c |2 +-
src/mesa/drivers/dri/intel/intel_regions.h |6 +++---
2 files changed, 4 insertions(+), 4 del
Right now the fake packed d/s RBs are creating two sub-renderbuffers
with their own storage, and the hardware setup and the mapping code
have been explicitly referencing them. By setting miptrees on them,
we'll be able to make our renderbuffer code for fake packed
depth/stencil more consistent wit
Before, we had an uncached read of S8 to untile, then a RMW (so
uncached penalty) of the packed S8Z24 to store the value, then the
consumer would uncached read that once per pixel. If data was written
to the map, we would then have to uncached read the written data back
out and do the scatter to t
This code will be incrementally moving to a model like intel_fbo.c's
renderbuffer mapping with helper functions, as I move that code here.
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 120 ++--
1 files changed, 71 insertions(+), 49 deletions(-)
diff --git a/src/mesa/d
This required is_hiz_depth_format to start returning true on S8_Z24 as
well, since that's the format we have here. The two previous callers
are only calling it on non-depthstencil formats.
This avoids us needing to have HiZ working on a new Z format
immediately upon exposing the format (particula
This will be used for things like packed depth/stencil temporaries and
making LLC-cached temporary mappings using blits.
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 37 ---
src/mesa/drivers/dri/intel/intel_mipmap_tree.h | 18 +++
2 files changed, 50 inserti
This will let us share teximage mapping logic with renderbuffer
mapping, which has an intel_mipmap_tree but not a gl_texture_image.
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 80
src/mesa/drivers/dri/intel/intel_mipmap_tree.h | 19 ++
src/mesa/drivers/dri
We're going to want to reuse this logic in mapping of fake packed
miptrees wrapping separate depth/stencil miptrees.
---
src/mesa/drivers/dri/intel/intel_fbo.c | 139 +---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 86 ++-
2 files changed, 112 inser
On 12/05/2011 08:02 PM, Jose Fonseca wrote:
>
>
> - Original Message -
>> On 11/19/2011 09:44 PM, Marek Olšák wrote:
>>> Hi everyone,
>>>
>>> this patch series implements all the core Mesa and Gallium support
>>> for EXT_transform_feedback and ARB_transform_feedback2. It's been
>>> tested
- Original Message -
> On 11/19/2011 09:44 PM, Marek Olšák wrote:
> > Hi everyone,
> >
> > this patch series implements all the core Mesa and Gallium support
> > for EXT_transform_feedback and ARB_transform_feedback2. It's been
> > tested by me on Radeons and by Christoph Bumiller on Nou
On 12/03/2011 09:07 AM, Brian Paul wrote:
No driver implemented this and we always returned "True" for residence
queries.
Most useless query evar.
Reviewed-by: Ian Romanick
Is there's some similar infrastructure for querying residence of ARB
vertex shaders? I think that can also die.
--
On 12/05/2011 07:56 AM, Brian Paul wrote:
On 12/03/2011 09:11 AM, Matt Turner wrote:
Hi,
It looks like there are a lot of LLVM-3.0 patches missing from the
7.11 branch, causing mesa-7.11.x to fail to build. See
https://bugs.gentoo.org/show_bug.cgi?id=393013
A users reports in that bug that whe
On 11/19/2011 09:44 PM, Marek Olšák wrote:
> Hi everyone,
>
> this patch series implements all the core Mesa and Gallium support for
> EXT_transform_feedback and ARB_transform_feedback2. It's been tested by me on
> Radeons and by Christoph Bumiller on Nouveau. I have verified that all
> transfo
In Gen6, transform feedback is accomplished by having the geometry
shader send vertex data to the data port using "Streamed Vertex Buffer
Write" messages, while simultaneously passing vertices through to the
rest of the graphics pipeline (if rendering is enabled).
This patch adds a geometry shader
R02_PRIM_END and R02_PRIM_START don't actually refer to bits in DWORD
2 of R0 (as the name, and comments in the code, would seem to
indicate). Actually they refer to bits in DWORD 2 of the header for
URB_WRITE messages.
This patch renames the defines to reflect what they actually mean. It
also a
Prior to this patch, in the Gen4 and Gen5 GS, we used GRF 0 (called
"R0" in the code) as a staging area to prepare the message header for
the FF_SYNC and URB_WRITE messages. This cleverly avoided an
unnecessary MOV operation (since the initial value of GRF 0 contains
data that needs to be included
From: Kenneth Graunke
The 50/50 split is just an attempt to get things working. We likely
want to tune this, and probably want to avoid allocating the GS any
space if we're not using it.
For now, this is good enough.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen6_urb.c |
From: Kenneth Graunke
We never filled this in before because we didn't care.
I'm skeptical these are correct; my sources indicate that both the VS
and GS # of entries are 256 on both GT1 and GT2.
I'm also loathe to change it and break stuff.
---
src/mesa/drivers/dri/i965/brw_context.c |2 +
The function convert_IF_ELSE_to_ADD() assumes that it doesn't have to
modify the destination and src0 fields of the instruction that it's
modifying, since prior to Gen6, IF and ELSE instructions use the IP
register in these fields.
In Gen6 and later, this is no longer true. Currently this isn't a
Normally when outputting instructions in SPF (single program flow)
mode, we convert IF and ELSE instructions to conditional ADD
instructions applied to the IP register, since this lets us avoid
having to emit an ENDIF instruction (and, in Gen4, lets us avoid using
up precious space in the MaskStack
Previously, GS generation code contained a lookup table that mapped
primitive types POLYGON, TRISTRIP, and TRIFAN to TRILIST, mapped
LINESTRIP to LINELIST, and left all other primitives unchanged. This
was silly, because we never generate a GS program for those primitive
types anyhow.
This patch
Previously, the geometry shader program key was storing all the
information necessary to compute the exact structure of the VUE map
(attrs and userclip_active). However, the GS program doesn't depend
on the exact structure of the VUE map; only on the size (in 256-bit
registers) of the VUE. So we
This patch adds a new bit to the ctx->NewState bitfield,
_NEW_TRANSFORM_FEEDBACK, to track state changes that affect
ctx->TransformFeedback. This bit can be used by driver back-ends to
avoid expensive recomputations when transform feedback state has not
been modified.
---
src/mesa/main/mtypes.h
This patch series introduces a geometry shader program for i965 Gen6
(Sandy Bridge) that does nothing--it simply passes vertices through to
later stages of the graphics pipeline. This is a preliminary step
towards implementing transform feedback, since on Gen6, transform
feedback is accomplished b
[ Moving to the mesa-dev mailing list ]
On Son, 2011-11-27 at 15:15 +0100, Hendrik Sattler wrote:
>
> I just upgraded to KDE-4.7.2 and Linux-3.1 and mostly when using Firefox, I
> get issues like a stall screen, then a short blank screen and then it works
> some time until that happens again.
- Original Message -
> On 12/05/2011 09:27 AM, Jose Fonseca wrote:
> > - Original Message -
> >> Implemented in terms of renderbuffer mapping/unmapping and format
> >> packing/unpacking functions.
> >>
> >> The swrast and state tracker code for implementing accumulation
> >> are
> >
On 12/05/2011 09:27 AM, Jose Fonseca wrote:
- Original Message -
Implemented in terms of renderbuffer mapping/unmapping and format
packing/unpacking functions.
The swrast and state tracker code for implementing accumulation are
unused and will be removed in the next commit.
v2: don't u
- Original Message -
> Implemented in terms of renderbuffer mapping/unmapping and format
> packing/unpacking functions.
>
> The swrast and state tracker code for implementing accumulation are
> unused and will be removed in the next commit.
>
> v2: don't use memcpy() in _mesa_clear_accum_
---
tests/spec/CMakeLists.txt |1 +
.../arb_uniform_buffer_object/CMakeLists.gl.txt| 17 ++
.../spec/arb_uniform_buffer_object/CMakeLists.txt |1 +
.../arb_uniform_buffer_object/standard-layout.c| 169
4 files changed, 188 insertion
On 12/03/2011 09:11 AM, Matt Turner wrote:
Hi,
It looks like there are a lot of LLVM-3.0 patches missing from the
7.11 branch, causing mesa-7.11.x to fail to build. See
https://bugs.gentoo.org/show_bug.cgi?id=393013
A users reports in that bug that when the following commits are
applied to mesa
On 12/05/2011 03:05 AM, Fabio Pedretti wrote:
The attached patches remove some unused-but-set-variables from mesa.
Reviewed-by: Brian Paul
Do you have git-push access?
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.fre
On 12/04/2011 08:18 AM, Henri Verbeet wrote:
This has no piglit regressions on r600g and softpipe.
Signed-off-by: Henri Verbeet
---
src/mesa/state_tracker/st_cb_texture.c | 174 +---
1 files changed, 91 insertions(+), 83 deletions(-)
Reviewed-by: Brian Paul
_
2011/12/5 zhigang gong :
> Hi Kristian,
>
> I'm integrating glamor with intel's video driver now. The basic idea
> is to allocate a BO
> by calling libdrm directly in intel uxa code path, then latter create
> an EGL image from
> that BO's handle. And then bind the image to a texture then glamor ca
On 12/04/2011 01:16 PM, Dave Airlie wrote:
From: Dave Airlie
This just adds the correct checks and asserts in the right places. This doesn't
fix all the tests that I've sent to piglit, need to add int paths to go
alongside the uint paths that don't go via float to fix it up properly.
I'm not s
On Mon, 2011-12-05 at 15:21 +0100, Thomas Hellstrom wrote:
>
> Currently the DRI state tracker sends the bits per pixel (bpp) value in
> the format member of a
> getbufferswithformat request, and assumes it can reinterpret the format
> of the returned buffer to something else
> with an identica
Hi!
Currently the DRI state tracker sends the bits per pixel (bpp) value in
the format member of a
getbufferswithformat request, and assumes it can reinterpret the format
of the returned buffer to something else
with an identical bpp.
That doesn't really work for vmwgfx. We can't reinterpret
Hi Kristian,
I'm integrating glamor with intel's video driver now. The basic idea
is to allocate a BO
by calling libdrm directly in intel uxa code path, then latter create
an EGL image from
that BO's handle. And then bind the image to a texture then glamor can
use it as usual.
Now the problem is
The attached patches remove some unused-but-set-variables from mesa.diff -purN mesa-7.12_orig//src/mesa/drivers/osmesa/osmesa.c mesa-7.12/src/mesa/drivers/osmesa/osmesa.c
--- mesa-7.12_orig//src/mesa/drivers/osmesa/osmesa.c 2011-06-10 12:05:04.0 +0200
+++ mesa-7.12/src/mesa/drivers/osmesa/o
https://bugs.freedesktop.org/show_bug.cgi?id=43520
Michel Dänzer changed:
What|Removed |Added
Summary|CoreBreach: Static |CoreBreach: Static lighting
Here is the final patch to enable dynamic eu instruction store size:
increase the brw eu instruction store size dynamically instead of just
allocating it statically with a constant limit. This would fix something
that 'GL_MAX_PROGRAM_INSTRUCTIONS_ARB was 16384 while the driver would
limit it to 100
If dynamic instruction store size is enabled, while after the brw_JMPI()
and before the brw_land_fwd_jump() function, the eu instruction store
base address(p->store) may change. Thus, the safe way to reference the
jmp instruction is by index instead of by the instruction address.
Signed-off-by: Yu
If dynamic instruction store size is enabled, while after the brw_DO()
and before the brw_WHILE() function, the eu instruction store base
address(p->store) may change.
Thus let brw_DO return the instruction index and brw_WHILE take the
do_insn index as the second parameter. And also let the loop_s
If dynamic instruction store size is enabled, while after the brw_IF/ELSE()
and before the brw_ENDIF() function, the eu instruction store base
address(p->store) may change.
Thus let if_stack just store the instruction pointer(an index). This is
somehow more flexible and safe than store the instruc
The reason to add a help function instead of just use 'insn - p->store'
instead is that this help function includes an assert.
Signed-off-by: Yuanhan Liu
---
src/mesa/drivers/dri/i965/brw_eu.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i96
If dynamic eu instruction store size is enabled, the eu instruction
store base address(p->store) may change. Like, in the following
situation:
struct brw_instruction *jmp = brw_JMPI(p, ...);
...
...
/* This somehow may change the p->store base address */
1) brw_emit_tri_setup(c,
76 matches
Mail list logo
