On Mit, 2011-09-21 at 10:31 -0600, Brian Paul wrote:
> On 09/21/2011 03:36 AM, Michel Dänzer wrote:
> > On Die, 2011-09-20 at 12:55 -0600, Brian Paul wrote:
> >> On 09/20/2011 10:40 AM, Michel Dänzer wrote:
> >>> On Don, 2011-09-15 at 13:01 -0600, Brian Paul wrote:
> On 09/15/2011 10:08 AM, Mi
On 09/22/2011 09:03 AM, Michel Dänzer wrote:
On Mit, 2011-09-21 at 10:31 -0600, Brian Paul wrote:
On 09/21/2011 03:36 AM, Michel Dänzer wrote:
On Die, 2011-09-20 at 12:55 -0600, Brian Paul wrote:
On 09/20/2011 10:40 AM, Michel Dänzer wrote:
On Don, 2011-09-15 at 13:01 -0600, Brian Paul wrote:
On 09/21/2011 05:56 PM, Brian Paul wrote:
From: Brian Paul
It's only used by swrast.
The useful thing of client-storage is that we could use it for
asynchronous texture uploads. With PBOs, there's not a lot of point.
For the series,
Reviewed-by: Ian Romanick
---
src/mesa/main/mtypes.
On 09/21/2011 10:15 AM, Eric Anholt wrote:
There were notes about the possibility of slowdowns due to zcopy from
a PBO due to thrashing around of the region. Slowdowns are even more
likely now that textures are generally tiled, which a zcopy wouldn't
get. Additionally, there were no checks on t
On 09/21/2011 10:15 AM, Eric Anholt wrote:
This came up in a chat with Chad a while back. I was in the area
because I'm planning out how to use the MapTextureImage changes to gut
even more of our texture code.
I made one trivial comment in 2/7. Regardless of the resolution there,
the series
On Thu, 22 Sep 2011 09:54:43 -0700, Ian Romanick wrote:
> On 09/21/2011 10:15 AM, Eric Anholt wrote:
> > There were notes about the possibility of slowdowns due to zcopy from
> > a PBO due to thrashing around of the region. Slowdowns are even more
> > likely now that textures are generally tiled,
This patch fix a "Unresolved Symbols" run time error when using G3DVL
through the VDPAU state tracker, by linking the vdpau targets with librt.
Reported by Arkadiusz Miśkiewicz.
Caused by this commit :
commit e911dbb56374edf9f3b7c4cec0cf9a22738bb198
Author: Emeric Grange
Date: Mon Sep 12 23:39
Very simple shaders don't actually use GLSL built-ins. For example:
- gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
- gl_FragColor = vec4(0.0);
Both of the shaders used by _mesa_meta_glsl_Clear() also qualify.
By waiting to initialize the built-ins until the first time we need to
look f
This makes this API consistent with intel_region_reference, and the
consumers consumers wanted it this way.
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 12 ++--
src/mesa/drivers/dri/intel/intel_tex_image.c|7 +--
src/mesa/drivers/dri/intel/intel_tex_validate.c |
Tested-by: Kristian Høgsberg
---
src/mesa/drivers/dri/intel/intel_tex_image.c | 104 --
1 files changed, 49 insertions(+), 55 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_tex_image.c
b/src/mesa/drivers/dri/intel/intel_tex_image.c
index 8fd69c3..15196c0 100
No change in piglit results on gen6.
---
src/mesa/drivers/dri/i965/gen6_cc.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen6_cc.c
b/src/mesa/drivers/dri/i965/gen6_cc.c
index b8047d5..1e6c4cf 100644
--- a/src/mesa/drivers/
A later patch to use Mesa core with MapTextureImage tripped over this
-- apparently we hadn't actually done it on a ->Data != NULL texture
before!
---
src/mesa/drivers/dri/intel/intel_tex.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/inte
Only 75 lines of code deletion to offer here.
My goal was to delete the whole CPU upload part of intelTexImage by
moving the mt setup to AllocTextureImageBuffer and using the
MapTextureImage-based Mesa core. However, because we don't have all
of core converted to MapTextureImage, there are places
We get called for TexImage higher up, and in a relatively normal way
(pixels == NULL is common for FBO setup).
---
src/mesa/drivers/dri/intel/intel_tex_image.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_tex_image.c
b/src/mesa/drive
Since I was working on some extensions to DRI2 protocol for handling
video, it occurred to me that it might be easier to extend the
protocol if there weren't N different copies of dri2.c floating around
in various different src trees.. also, for video, with one or two
other small extensions (ie. s
On 09/22/2011 01:34 PM, Eric Anholt wrote:
Only 75 lines of code deletion to offer here.
My goal was to delete the whole CPU upload part of intelTexImage by
moving the mt setup to AllocTextureImageBuffer and using the
MapTextureImage-based Mesa core. However, because we don't have all
of core c
It will do a more reliable job at getting the image size for
_mesa_texstore right than us.
---
src/mesa/drivers/dri/intel/intel_tex_image.c | 24 +---
1 files changed, 5 insertions(+), 19 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_tex_image.c
b/src/mesa/driv
We call all the other drm_intel_bo pointers in intel/*.h "bo", so this
one was rather out of place.
---
src/mesa/drivers/dri/i915/i830_texstate.c |4 +-
src/mesa/drivers/dri/i915/i830_vtbl.c |8 +++---
src/mesa/drivers/dri/i915/i915_texstate.c |4 +-
src/mes
There's nothing in our normal texture path we need for this. We don't
PBO upload blit it. We don't need to worry about flushing because
MapTextureImage handles it. hiz scattergather doesn't apply, but MTI
handles it too.
---
src/mesa/drivers/dri/intel/intel_tex_image.c | 78 +++---
It's totally gratuitous -- the image's miptree will be checked for
binding to the object later, anyway, with zero-copy or blitting as
appropriate.
Tested-by: Kristian Høgsberg
---
src/mesa/drivers/dri/intel/intel_tex_image.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
d
If there happened to be ->Data present, we assertion failed instead of
handling it correctly.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35234
---
src/mesa/drivers/dri/intel/intel_tex_image.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers
_mesa_reference_renderbuffer already short-circuits equality, and
intel_miptree_release does nothing on NULL.
---
src/mesa/drivers/dri/intel/intel_fbo.c | 13 -
src/mesa/drivers/dri/intel/intel_tex.c | 17 -
2 files changed, 8 insertions(+), 22 deletions(-)
diff --
We don't have it in the other refcounting functions, and it was
totally unused.
---
src/mesa/drivers/dri/intel/intel_fbo.c |2 +-
src/mesa/drivers/dri/intel/intel_mipmap_tree.c |3 +--
src/mesa/drivers/dri/intel/intel_mipmap_tree.h |3 +--
src/mesa/drivers/dri/intel/intel_te
On Wed, 21 Sep 2011 18:56:53 -0600, Brian Paul wrote:
> From: Brian Paul
>
> These fields were only used for swrast so move them into
> swrast_texture_image.
> diff --git a/src/mesa/swrast/s_texture.c b/src/mesa/swrast/s_texture.c
> index 14ee0eb..1dcb08c 100644
> --- a/src/mesa/swrast/s_texture
On Thu, 22 Sep 2011 14:37:24 -0600, Brian Paul wrote:
> On 09/22/2011 01:34 PM, Eric Anholt wrote:
> > Only 75 lines of code deletion to offer here.
> >
> > My goal was to delete the whole CPU upload part of intelTexImage by
> > moving the mt setup to AllocTextureImageBuffer and using the
> > MapT
On Thu, 22 Sep 2011 12:41:21 -0700, Kenneth Graunke
wrote:
> Very simple shaders don't actually use GLSL built-ins. For example:
> - gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
> - gl_FragColor = vec4(0.0);
> Both of the shaders used by _mesa_meta_glsl_Clear() also qualify.
>
> By w
Without this we'd miss the last update in a sequence like {COLOR0, COLOR1},
{COLOR0}, {COLOR0, COLOR1}. I originally had a patch for this that called
updated_drawbuffers() when the buffer count changed, but later realized that
was wrong. The ARB_draw_buffers spec explicitly says "The draw buffer fo
On 09/22/2011 03:13 PM, Eric Anholt wrote:
On Wed, 21 Sep 2011 18:56:53 -0600, Brian Paul wrote:
From: Brian Paul
These fields were only used for swrast so move them into
swrast_texture_image.
diff --git a/src/mesa/swrast/s_texture.c b/src/mesa/swrast/s_texture.c
index 14ee0eb..1dcb08c 100644
Found by inspection.
Signed-off-by: Kenneth Graunke
---
src/glsl/opt_tree_grafting.cpp | 37 ++---
1 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/src/glsl/opt_tree_grafting.cpp b/src/glsl/opt_tree_grafting.cpp
index 22a1749..d9ab2e6 100644
---
On 09/22/2011 12:36 PM, Eric Anholt wrote:
> No change in piglit results on gen6.
> ---
> src/mesa/drivers/dri/i965/gen6_cc.c | 20
> 1 files changed, 20 insertions(+), 0 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/gen6_cc.c
> b/src/mesa/drivers/dri/i965/gen6_c
On 09/22/2011 03:48 PM, Henri Verbeet wrote:
Without this we'd miss the last update in a sequence like {COLOR0, COLOR1},
{COLOR0}, {COLOR0, COLOR1}. I originally had a patch for this that called
updated_drawbuffers() when the buffer count changed, but later realized that
was wrong. The ARB_draw_b
This makes the code a lot cleaner, and theoretically faster (not many
real world tests use this GL extension).
Cc: Eric Anholt
Cc: Daniel Vetter
Cc: Mesa Devs
Signed-off-by: Ben Widawsky
---
src/mesa/drivers/dri/intel/intel_buffer_objects.c | 48 ++--
1 files changed, 5 inse
On Thu, 22 Sep 2011 23:48:23 +0200, Henri Verbeet wrote:
> Without this we'd miss the last update in a sequence like {COLOR0, COLOR1},
> {COLOR0}, {COLOR0, COLOR1}. I originally had a patch for this that called
> updated_drawbuffers() when the buffer count changed, but later realized that
> was wr
On 09/22/2011 12:34 PM, Eric Anholt wrote:
> Only 75 lines of code deletion to offer here.
>
> My goal was to delete the whole CPU upload part of intelTexImage by
> moving the mt setup to AllocTextureImageBuffer and using the
> MapTextureImage-based Mesa core. However, because we don't have all
>
From: Brian Paul
This code is about to stop needing ->Data and using MapTextureImage().
---
src/mesa/main/texgetimage.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index 4d58309..a5e499a 100644
--- a/src
Here's an extract of what I had in one of my branches for mti, with a
slight cleanup to reduce diffs in texgetimage.c. Tested on i965 and
softpipe. This code can also be found in the mti-getteximage branch
of my personal tree.
___
mesa-dev mailing list
From: Brian Paul
This changes drivers to not map the texture on their own before
calling _mesa_get_compressed_teximage().
---
src/mesa/drivers/dri/intel/intel_tex_image.c | 47 +++--
src/mesa/drivers/dri/radeon/radeon_tex_getimage.c | 45
src/mesa/dr
From: Brian Paul
---
src/mesa/main/texgetimage.c | 17 -
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index e568607..199fb5c 100644
--- a/src/mesa/main/texgetimage.c
+++ b/src/mesa/main/texgetimage.c
@
From: Brian Paul
---
src/mesa/main/texgetimage.c | 24 +++-
1 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index a5e499a..e568607 100644
--- a/src/mesa/main/texgetimage.c
+++ b/src/mesa/main/texgetim
From: Brian Paul
---
src/mesa/main/texgetimage.c| 19 ---
src/mesa/state_tracker/st_cb_texture.c |3 ++-
2 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index fdf0e1a..11494e5 100644
--- a
From: Brian Paul
---
src/mesa/main/texgetimage.c| 16 ++---
src/mesa/state_tracker/st_cb_texture.c | 38
2 files changed, 12 insertions(+), 42 deletions(-)
diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index 11494
The mesa core code uses MapTextureImage() like we need now.
---
src/mesa/drivers/dri/intel/intel_tex_image.c | 61 --
1 files changed, 0 insertions(+), 61 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_tex_image.c
b/src/mesa/drivers/dri/intel/intel_tex_image
From: Brian Paul
Note that the implementation before and after appears to be broken in
its handling of Z24_S8 vs S8_Z24.
---
src/mesa/main/texgetimage.c| 18 +-
src/mesa/state_tracker/st_cb_texture.c | 11 ---
2 files changed, 21 insertions(+), 8 deletions
It's handled by MapTextureImage() now.
---
src/mesa/drivers/dri/nouveau/nouveau_texture.c | 14 --
1 files changed, 0 insertions(+), 14 deletions(-)
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_texture.c
b/src/mesa/drivers/dri/nouveau/nouveau_texture.c
index 320bc8c..9dc2186 1
It's handled by MapTextureImage() now.
---
src/mesa/drivers/dri/r200/Makefile|1 -
src/mesa/drivers/dri/r300/Makefile|1 -
src/mesa/drivers/dri/r600/Makefile|1 -
src/mesa/drivers/dri/radeon/Makefile |1 -
src/mesa/driver
On 23 September 2011 01:48, Eric Anholt wrote:
> In the case of n == 1 with more than one bit set, doesn't this stomp the
> _ColorDrawBufferIndexes[] we just calculated between n and
> _NumColorDrawBuffers - 1? Looks like splitting that loop into two would
> work well.
>
You're right, how about s
On Thu, Sep 22, 2011 at 6:14 PM, Eric Anholt wrote:
> Here's an extract of what I had in one of my branches for mti, with a
> slight cleanup to reduce diffs in texgetimage.c. Tested on i965 and
> softpipe. This code can also be found in the mti-getteximage branch
> of my personal tree.
I'll try
On Thu, Sep 08, 2011 at 09:14:08PM -0700, Kenneth Graunke wrote:
> i915_miptree_layout, i945_miptree_layout, and brw_miptree_layout always
> just return GL_TRUE, so there's really no point to it. Change them to
> void functions and remove the (dead) error checking code.
Reviewed-by: Yuanhan Liu
On Thu, Sep 08, 2011 at 09:12:44PM -0700, Kenneth Graunke wrote:
> On 09/08/2011 07:56 PM, Yuanhan Liu wrote:
> > There is already comments show how to detect a null texture. Fix the
> > code to match the comments.
> >
> > This would fix the oglc divzero(basic.texQOrWEqualsZero) and
> > divzero(ba
On Thu, Sep 15, 2011 at 04:02:49PM +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 misctest(basic.textureBorderIgnore) fail.
Hello, any comments on this
On Mon, Sep 19, 2011 at 06:25:54PM +0800, Yuanhan Liu wrote:
> If I understand correctly, the new GL3 buffer object queries parameters,
> like BUFFER_MAP_ACCESS_FLAGS, depends on ARB_map_buffer_range
> extension.
Hello,
Any more comments?
BTW, it doesn't make sense for me that we can set the acc
On Fri, 23 Sep 2011 11:09:14 +0800, Yuanhan Liu
wrote:
> On Thu, Sep 08, 2011 at 09:12:44PM -0700, Kenneth Graunke wrote:
> > On 09/08/2011 07:56 PM, Yuanhan Liu wrote:
> > > There is already comments show how to detect a null texture. Fix the
> > > code to match the comments.
> > >
> > > This w
On Thu, Sep 22, 2011 at 10:26:37PM -0700, Eric Anholt wrote:
> On Fri, 23 Sep 2011 11:09:14 +0800, Yuanhan Liu
> wrote:
> > On Thu, Sep 08, 2011 at 09:12:44PM -0700, Kenneth Graunke wrote:
> > > On 09/08/2011 07:56 PM, Yuanhan Liu wrote:
> > > > There is already comments show how to detect a null
53 matches
Mail list logo
