On 04/29/2014 10:57 PM, Timothy Arceri wrote:
Looks like this patch should have been dropped with the removal of
user_location?
Nope. We still need to track the location set in the shader. Now it's
tracked in the same location field as, say, vertex shader inputs instead
of having a special
Ping.
-Brian
On 04/24/2014 03:29 PM, Brian Paul wrote:
The original GL_EXT_texture_swizzle extensions said GL_INVALID_OPERATION
was to be generated when the an invalid swizzle was passed to
glTexParameter(). But in OpenGL 3.3 and later, the error should be
GL_INVALID_ENUM.
---
https://bugs.freedesktop.org/show_bug.cgi?id=78101
--- Comment #4 from Scott Moreau ore...@gmail.com ---
(In reply to comment #3)
Created attachment 98234 [details] [review]
hopeful patch to fix the issue
I'm having problems configuring demos build system to reproduce this ...
No special
On 04/24/2014 02:29 PM, Brian Paul wrote:
The original GL_EXT_texture_swizzle extensions said GL_INVALID_OPERATION
was to be generated when the an invalid swizzle was passed to
glTexParameter(). But in OpenGL 3.3 and later, the error should be
GL_INVALID_ENUM.
Reviewed-by: Ian Romanick
On 04/29/2014 08:43 PM, Chia-I Wu wrote:
On Wed, Apr 30, 2014 at 8:52 AM, Ian Romanick i...@freedesktop.org wrote:
From: Ian Romanick ian.d.roman...@intel.com
This code was broken in some odd ways before. Too much state was being
saved, it was being restored in the wrong order, and in the
https://bugs.freedesktop.org/show_bug.cgi?id=78101
--- Comment #5 from Ian Romanick i...@freedesktop.org ---
The demos need to use eglGetProcAddress for extension functions. The patch is
the right approach, but having a non-static function pointer with the same name
as a function is very
On Tue, Apr 29, 2014 at 01:21:11PM -0700, Eric Anholt wrote:
Chad Versace chad.vers...@linux.intel.com writes:
On Mon, Mar 24, 2014 at 09:07:32AM +1000, Dave Airlie wrote:
On Sat, Mar 8, 2014 at 12:13 AM, Pohjolainen, Topi
topi.pohjolai...@intel.com wrote:
On Mon, Mar 03, 2014 at
https://bugs.freedesktop.org/show_bug.cgi?id=78123
Priority: medium
Bug ID: 78123
Assignee: mesa-dev@lists.freedesktop.org
Summary: svga prints out command errors
Severity: critical
Classification: Unclassified
OS: Linux
The relevant code:
if (slab-free == 0) {
LIST_DEL(slab-head);
LIST_ADD(slab-head, bucket-full);
}
And the LIST_ADD is line 206 (on the 9.2 branch).
Do you know if multiple GL threads are used? I looked at the code, and
it seems perfectly fine, and hasn't changed in forever
https://bugs.freedesktop.org/show_bug.cgi?id=78101
--- Comment #6 from Tapani Pälli lem...@gmail.com ---
(In reply to comment #5)
The demos need to use eglGetProcAddress for extension functions. The patch
is the right approach, but having a non-static function pointer with the
same name as a
On 04/30/2014 03:21 AM, Petri Latvala wrote:
On 04/29/2014 09:57 PM, Matt Turner wrote:
On Tue, Apr 29, 2014 at 6:01 AM, Petri Latvala
petri.latv...@intel.com wrote:
For the record, tested this with the following shader:
Cool. Please submit this as a piglit test.
Sent to piglit mailing
v2:
- Write RASTER_CONFIG for all SEs
https://bugs.freedesktop.org/show_bug.cgi?id=60879
---
src/gallium/drivers/radeonsi/si_state.c | 100 --
src/gallium/drivers/radeonsi/sid.h| 8 +-
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 3 +
Ilia, thank you for looking at it.
On 04/30/2014 12:47 PM, Ilia Mirkin wrote:
The relevant code:
if (slab-free == 0) {
LIST_DEL(slab-head);
LIST_ADD(slab-head, bucket-full);
}
And the LIST_ADD is line 206 (on the 9.2 branch).
Do you know if multiple GL threads are
Ian Romanick i...@freedesktop.org writes:
From: Ian Romanick ian.d.roman...@intel.com
This will be used for GL_ARB_separate_shader_objects. That extension
not only allows separable shaders to rendezvous by location, but it also
allows traditionally linked shaders to rendezvous by location.
Ian Romanick i...@freedesktop.org writes:
A lot the patches in this series were slightly reworked to incorporate
Eric's feedback (remove ir_variable::user_location) on the previous
attempt. Other than that change, I patch 1 is new, and patch 16 adds
previously missing display list support.
Kenneth Graunke kenn...@whitecape.org writes:
On 04/29/2014 04:34 PM, Eric Anholt wrote:
[snip]
@@ -558,12 +572,8 @@ intel_dup_image(__DRIimage *orig_image, void
*loaderPrivate)
if (image == NULL)
return NULL;
- intel_region_reference(image-region, orig_image-region);
-
Now that we are uisng the OpenCL 1.2 headers, applications expect all
the OpenCL 1.2 functions to be implemented.
This fixes linking errors with the piglit CL tests.
---
src/gallium/state_trackers/clover/api/dispatch.cpp | 2 +-
src/gallium/state_trackers/clover/api/dispatch.hpp | 8 +++-
Chad Versace chad.vers...@linux.intel.com writes:
On Mon, Apr 21, 2014 at 02:08:49PM -0700, Kenneth Graunke wrote:
HiZ operations make the depth/render caches out of sync with the sampler
caches. We need to arrange for a TC flush to happen before the target
buffer is used by the sampler.
On 04/24/2014 05:50 PM, Eric Anholt wrote:
The field wasn't really valid, since we've got more than 32 units now. It
turns out it was mostly just used for checking != 0, or checking for fixed
function coordinates, though.
---
src/mesa/drivers/common/meta.c | 2 +-
Kenneth Graunke kenn...@whitecape.org writes:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77221
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
diff --git a/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
b/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
index
Kenneth Graunke kenn...@whitecape.org writes:
This is similar to what Eric did for Gen7 a little while ago; it also
has support for untyped surface reads.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/gen8_disasm.c | 65
Kenneth Graunke kenn...@whitecape.org writes:
This must not have existed when I wrote the original code. The atomic
operation header setup code uses this.
Other than the tiny comments I had, this series is:
Reviewed-by: Eric Anholt e...@anholt.net
pgp9IHfdw8ZUH.pgp
Description: PGP
On 04/25/2014 06:19 PM, Eric Anholt wrote:
No more walking 96*6 pointers looking to see if they're the current
texture, when we only use the first 2 out of 96 units. -6.26002% +/-
1.87817% effect on cairo runtime on no-fbo-cache glamor (n=36).
---
src/mesa/main/mtypes.h | 3 +++
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/gallium/drivers/nouveau/nouveau_buffer.c | 4 +---
src/gallium/drivers/nouveau/nouveau_context.h | 1 -
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nouveau_buffer.c
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
Light testing with dolphin-emu on a G96, seems to mostly work. Saw one or two
glitches (for like 1 frame), but that could well have been a bug in the emu.
It's a little silly to have all this super-super-repetitive code, but short of
On 03/21/2014 03:01 PM, Anuj Phogat wrote:
_mesa_texstore_z24_s8() and _mesa_texstore_z32f_x24s8() are capable of
handling GL_DEPTH_STENCIL format. So, allow it in both the functions.
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
Patches 1, 2, 4, 5, 6 (with the small change suggested), 7, 8, 9, and 10
are all
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
On 03/21/2014 03:01 PM, Anuj Phogat wrote:
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
src/mesa/main/mtypes.h |
Sorry to waste more of your time but this is driving me nuts. For my own
education :) can you tell me how this code works? Maybe I'm making
myself look silly by not understanding some basic concept of c++. But to
me it looks like var-data.location already contains the explicit
location and you are
On 04/30/2014 12:40 PM, Eric Anholt wrote:
Ian Romanick i...@freedesktop.org writes:
From: Ian Romanick ian.d.roman...@intel.com
This will be used for GL_ARB_separate_shader_objects. That extension
not only allows separable shaders to rendezvous by location, but it also
allows
On 04/30/2014 12:41 PM, Eric Anholt wrote:
Ian Romanick i...@freedesktop.org writes:
A lot the patches in this series were slightly reworked to incorporate
Eric's feedback (remove ir_variable::user_location) on the previous
attempt. Other than that change, I patch 1 is new, and patch 16
From: Roland Scheidegger srol...@vmware.com
c703658b3965bf2e4f3593a0d54be03e8e8b1436 used
Texture.MaxEnabledTexImageUnit instead of Texture._MaxEnabledTexImageUnit.
---
src/mesa/drivers/osmesa/osmesa.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Roland Scheidegger srol...@vmware.com
don't leak the MCSubtargetInfo (not really big, was already fixed with
llvm master) and TargetMachine (big). While this is only used for debugging
the leak is large enough to get you into trouble in some cases.
Tested with llvm 3.1 and master.
Before
From: Samuel Li samuel...@amd.com
Signed-off-by: Samuel Li samuel...@amd.com
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
lib/Target/R600/Processors.td | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/Target/R600/Processors.td b/lib/Target/R600/Processors.td
index
From: Roland Scheidegger srol...@vmware.com
---
src/glx/drisw_glx.c |1 +
1 file changed, 1 insertion(+)
diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c
index 751626b..5885b66 100644
--- a/src/glx/drisw_glx.c
+++ b/src/glx/drisw_glx.c
@@ -619,6 +619,7 @@ driswDestroyScreen(struct
On 04/30/2014 02:26 PM, Timothy Arceri wrote:
Sorry to waste more of your time but this is driving me nuts. For my own
education :) can you tell me how this code works? Maybe I'm making
myself look silly by not understanding some basic concept of c++. But to
me it looks like var-data.location
On 04/30/2014 04:41 PM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
c703658b3965bf2e4f3593a0d54be03e8e8b1436 used
Texture.MaxEnabledTexImageUnit instead of Texture._MaxEnabledTexImageUnit.
---
src/mesa/drivers/osmesa/osmesa.c |2 +-
1 file changed, 1
On 04/30/2014 05:04 PM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
---
src/glx/drisw_glx.c |1 +
1 file changed, 1 insertion(+)
diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c
index 751626b..5885b66 100644
--- a/src/glx/drisw_glx.c
+++
From: Samuel Li samuel...@amd.com
Signed-off-by: Samuel Li samuel...@amd.com
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
include/pci_ids/radeonsi_pci_ids.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/pci_ids/radeonsi_pci_ids.h
From: Samuel Li samuel...@amd.com
Signed-off-by: Samuel Li samuel...@amd.com
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
src/gallium/drivers/radeon/r600_pipe_common.c | 2 ++
src/gallium/drivers/radeonsi/si_state.c | 2 ++
For the series:
Reviewed-by: Marek Olšák marek.ol...@amd.com
Marek
On Thu, May 1, 2014 at 1:30 AM, Alex Deucher alexdeuc...@gmail.com wrote:
From: Samuel Li samuel...@amd.com
Signed-off-by: Samuel Li samuel...@amd.com
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
On 04/30/2014 04:41 PM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
don't leak the MCSubtargetInfo (not really big, was already fixed with
llvm master) and TargetMachine (big). While this is only used for debugging
the leak is large enough to get you into trouble in
Ian Romanick i...@freedesktop.org writes:
On 04/30/2014 12:41 PM, Eric Anholt wrote:
Ian Romanick i...@freedesktop.org writes:
A lot the patches in this series were slightly reworked to incorporate
Eric's feedback (remove ir_variable::user_location) on the previous
attempt. Other than
BTW, we may need to release libdrm_radeon first before we can commit this.
Marek
On Thu, May 1, 2014 at 1:30 AM, Alex Deucher alexdeuc...@gmail.com wrote:
From: Samuel Li samuel...@amd.com
Signed-off-by: Samuel Li samuel...@amd.com
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
On Thu, May 1, 2014 at 12:11 AM, Ian Romanick i...@freedesktop.org wrote:
On 04/29/2014 08:43 PM, Chia-I Wu wrote:
On Wed, Apr 30, 2014 at 8:52 AM, Ian Romanick i...@freedesktop.org wrote:
From: Ian Romanick ian.d.roman...@intel.com
This code was broken in some odd ways before. Too much
On Tue, Apr 29, 2014 at 4:34 PM, Eric Anholt e...@anholt.net wrote:
---
src/mesa/drivers/dri/i965/intel_screen.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
Oh, right, I forgot about the __DRIbuffer usage. This really show how
intel_region just
On Tue, Apr 29, 2014 at 4:34 PM, Eric Anholt e...@anholt.net wrote:
I want to do this to get the region removed from DRI images. However, it
does mean that we won't share the intel_region between the rb and the
texture for texture_from_pixmap. I think that's fine.
My review got stuck on this
Patches 1-3 are
Reviewed-by: Chad Versace chad.vers...@linux.intel.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
/**
+ * This function computes masks that may be used to select the bits of the X
+ * and Y coordinates that indicate the offset within a tile. If the region
is
Tiny nit --- ^^
+ * untiled, the masks are set to 0.
+ */
But
@@ -856,16 +856,16 @@ gen6_blorp_emit_depth_stencil_config(struct brw_context
*brw,
/* 3DSTATE_HIER_DEPTH_BUFFER */
{
- struct intel_region *hiz_region = params-depth.mt-hiz_mt-region;
+ struct intel_mipmap_tree *hiz_mt = params-depth.mt-hiz_mt;
While you're on a data
Reviewed-by: Chad Versace chad.vers...@linux.intel.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
50 matches
Mail list logo
