On Tue, Apr 29, 2014 at 04:34:36PM -0700, Eric Anholt wrote:
> Regions aren't refcounted safely for multithreaded applications, and
> they're not terribly useful wrappers of a BO, so I'm trying to remove
> them.
>
> Even the stride I added here could probably be reduced to use of an
> existing fie
On 04/07/2014 08:47 AM, Ian Romanick wrote:
> On 03/13/2014 08:15 AM, Mika Kuoppala wrote:
>> Ian Romanick writes:
>>
>>> On 03/12/2014 01:43 AM, Kenneth Graunke wrote:
arekm reported that using Chrome with GPU acceleration enabled on GM45
triggered the hw_ctx != NULL assertion in brw_ge
On Tue, Apr 29, 2014 at 04:34:35PM -0700, Eric Anholt 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.
Sounds right to me. Embedding th
On Tue, Apr 29, 2014 at 04:34:34PM -0700, Eric Anholt wrote:
> I noticed that we were doing this while changing the DRI3 path to not use
> regions, which involved changing the signature of
> intel_update_winsys_renderbuffer_miptree() this way.
> ---
> src/mesa/drivers/dri/i965/brw_context.c
On Wed, Apr 30, 2014 at 11:25:27PM -0700, Chad Versace wrote:
> On Tue, Apr 29, 2014 at 04:34:33PM -0700, Eric Anholt wrote:
> > Once a buffer has been named, drm_intel_bo_flink() is just a getter.
>
> Yep. Surprising but true. (Well, it surprised me).
>
> > diff --git a/src/mesa/drivers/dri/i965
On Tue, Apr 29, 2014 at 04:34:33PM -0700, Eric Anholt wrote:
> Once a buffer has been named, drm_intel_bo_flink() is just a getter.
Yep. Surprising but true. (Well, it surprised me).
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c
> b/src/mesa/drivers/dri/i965/brw_context.c
> index 28118b
On Tue, Apr 29, 2014 at 04:34:32PM -0700, Eric Anholt wrote:
> The drm function to get the tiling is just a getter storing the two
> pointers, so we don't need to go out of our way to avoid it.
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965/intel_mipmap
Reviewed-by: Chad Versace
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> @@ -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
> /**
> + * 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.
> + */
B
Patches 1-3 are
Reviewed-by: Chad Versace
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, Apr 29, 2014 at 4:34 PM, Eric Anholt 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 one as I tho
On Tue, Apr 29, 2014 at 4:34 PM, Eric Anholt 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 added redundancy.
On Thu, May 1, 2014 at 12:11 AM, Ian Romanick wrote:
> On 04/29/2014 08:43 PM, Chia-I Wu wrote:
>> On Wed, Apr 30, 2014 at 8:52 AM, Ian Romanick wrote:
>>> From: Ian Romanick
>>>
>>> This code was broken in some odd ways before. Too much state was being
>>> saved, it was being restored in the w
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 wrote:
> From: Samuel Li
>
> Signed-off-by: Samuel Li
> Signed-off-by: Alex Deucher
> ---
> src/gallium/drivers/radeon/r600_pipe_common.c | 2 ++
> src/gallium/dr
Ian Romanick writes:
> On 04/30/2014 12:41 PM, Eric Anholt wrote:
>> Ian Romanick 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,
On 04/30/2014 04:41 PM, srol...@vmware.com wrote:
From: Roland Scheidegger
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 wi
For the series:
Reviewed-by: Marek Olšák
Marek
On Thu, May 1, 2014 at 1:30 AM, Alex Deucher wrote:
> From: Samuel Li
>
> Signed-off-by: Samuel Li
> Signed-off-by: Alex Deucher
> ---
> src/gallium/drivers/radeon/r600_pipe_common.c | 2 ++
> src/gallium/drivers/radeonsi/si_state.c
From: Samuel Li
Signed-off-by: Samuel Li
Signed-off-by: Alex Deucher
---
src/gallium/drivers/radeon/r600_pipe_common.c | 2 ++
src/gallium/drivers/radeonsi/si_state.c | 2 ++
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 1 +
src/gallium/winsys/radeon/drm/radeon_winsys.h
From: Samuel Li
Signed-off-by: Samuel Li
Signed-off-by: Alex Deucher
---
include/pci_ids/radeonsi_pci_ids.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/pci_ids/radeonsi_pci_ids.h
b/include/pci_ids/radeonsi_pci_ids.h
index 7b42d5e..5099c74 100644
--- a/includ
On 04/30/2014 05:04 PM, srol...@vmware.com wrote:
From: Roland Scheidegger
---
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
On 04/30/2014 04:41 PM, srol...@vmware.com wrote:
From: Roland Scheidegger
c703658b3965bf2e4f3593a0d54be03e8e8b1436 used
Texture.MaxEnabledTexImageUnit instead of Texture._MaxEnabledTexImageUnit.
---
src/mesa/drivers/osmesa/osmesa.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
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.locat
From: Roland Scheidegger
---
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 glx_screen *base)
From: Samuel Li
Signed-off-by: Samuel Li
Signed-off-by: Alex Deucher
---
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 fde4481..ce17d7c 100644
--- a/lib/Target/R600/Processors.td
+++ b/lib
From: Roland Scheidegger
c703658b3965bf2e4f3593a0d54be03e8e8b1436 used
Texture.MaxEnabledTexImageUnit instead of Texture._MaxEnabledTexImageUnit.
---
src/mesa/drivers/osmesa/osmesa.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/osmesa/osmesa.c b/src/mes
From: Roland Scheidegger
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 (llvm 3.1), GALLIVM_D
On 04/30/2014 12:40 PM, Eric Anholt wrote:
> Ian Romanick writes:
>
>> From: Ian Romanick
>>
>> 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 b
On 04/30/2014 12:41 PM, Eric Anholt wrote:
> Ian Romanick 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
>> previous
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
Patches 1, 2, 4, 5, 6 (with the small change suggested), 7, 8, 9, and 10
are all
Reviewed-by: Ian Romanick
On 03/21/2014 03:01 PM, Anuj Phogat wrote:
> Cc:
> Signed-off-by: Anuj Phogat
> ---
> src/mesa/main/mtypes.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/mesa/main/mtype
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:
> Signed-off-by: Anuj Phogat
> ---
> src/mesa/main/texstore.c | 6 --
> 1 file changed, 4 inser
Signed-off-by: Ilia Mirkin
---
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
b/src/gallium/drivers/nouveau/nouveau_buffer.c
in
Signed-off-by: Ilia Mirkin
---
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
rearranging the drivers, no eas
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 +++
> src
Kenneth Graunke 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
pgp9IHfdw8ZUH.pgp
Description: PGP signature
Kenneth Graunke writes:
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77221
> Signed-off-by: Kenneth Graunke
> diff --git a/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
> b/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
> index dae4026..fffde0c 100644
> --- a/src/mesa/drivers/dr
Kenneth Graunke 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
> ---
> src/mesa/drivers/dri/i965/gen8_disasm.c | 65
> +
> 1 file changed, 65 insertions(
Kenneth Graunke writes:
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77221
> Signed-off-by: Kenneth Graunke
> diff --git a/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
> b/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
> index 856a23e..dae4026 100644
> --- a/src/mesa/drivers/dr
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 +-
> src
Chad Versace 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. Calling brw_render_cache
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 +++-
s
Kenneth Graunke 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);
>> - if
Ian Romanick 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.
Patch 2, 3, 13, 1
Ian Romanick writes:
> From: Ian Romanick
>
> 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. The spec
> says:
>
> 36. How does t
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
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 +
src
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
>> wrote:
>>> For the record, tested this with the following shader:
>>>
>>>
>> Cool. Please submit this as a piglit test.
>
> Sent to piglit mailing list, w
https://bugs.freedesktop.org/show_bug.cgi?id=78101
--- Comment #6 from Tapani Pälli ---
(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 function is ve
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 forev
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 (All
On Tue, Apr 29, 2014 at 01:21:11PM -0700, Eric Anholt wrote:
> Chad Versace 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
> >> wrote:
> >> > On Mon, Mar 03, 2014 at 01:19:48PM +1000, Dave Airlie wrote:
> >> >> T
https://bugs.freedesktop.org/show_bug.cgi?id=78101
--- Comment #5 from Ian Romanick ---
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 dangerous. You wouldn't dec
On 04/29/2014 08:43 PM, Chia-I Wu wrote:
> On Wed, Apr 30, 2014 at 8:52 AM, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> 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 wrong way.
>> The biggest problem was
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
https://bugs.freedesktop.org/show_bug.cgi?id=78101
--- Comment #4 from Scott Moreau ---
(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 configuration f
On 04/29/2014 05:52 PM, Ian Romanick wrote:
> 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 suppor
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.
---
src/mesa/main/
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 f
Change '#include "drm/drm.h"' to '#include "drm.h"' as it is also
done in other _drm.h files. This helps to enable KMS
support in xf86-video-qxl driver.
Signed-Off-by: Stefan Dirsch
---
include/drm/qxl_drm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/qxl_drm.
I'm running Minecraft 1.7.9
on Fedora 19 x86_64
with mesa-dri-drivers-9.2.4-1.20131128.fc19.x86_64.
lspci says my graphics card is :
01:00.0 VGA compatible controller: NVIDIA Corporation G86 [Quadro
NVS 290] (rev a1)
The the console output says :
A fatal error has been detected by the Java Ru
https://bugs.freedesktop.org/show_bug.cgi?id=78101
--- Comment #3 from Tapani Pälli ---
Created attachment 98234
--> https://bugs.freedesktop.org/attachment.cgi?id=98234&action=edit
hopeful patch to fix the issue
I'm having problems configuring demos build system to reproduce this ...
however
On 04/29/2014 09:57 PM, Matt Turner wrote:
On Tue, Apr 29, 2014 at 6:01 AM, Petri Latvala wrote:
For the record, tested this with the following shader:
Cool. Please submit this as a piglit test.
Sent to piglit mailing list, with accompanying tests for min3 and max3.
Wouldn't it be simpler
https://bugs.freedesktop.org/show_bug.cgi?id=78101
--- Comment #2 from Scott Moreau ---
(In reply to comment #1)
> did you run make with a clean directory (make clean or git clean -fdX)?
Yes. demos build and link with mesa dfccd5ccd73ec8e9607826c62fb6bf31f9628719
but linking fails with mesa 1a59
https://bugs.freedesktop.org/show_bug.cgi?id=78101
Tapani Pälli changed:
What|Removed |Added
CC||lem...@gmail.com
--- Comment #1 from Tapa
On 30/04/14 00:10, Eric Le Bihan wrote:
> On Tue, Apr 29, 2014 at 02:04:25AM +0100, Emil Velikov wrote:
>> On 28/04/14 22:56, Eric Le Bihan wrote:
>>> Hi!
>>>
>>> I'm currently cross-compiling Mesa3d for embedded systems using the
>>> following configure options:
>>>
>>> --enable-shared --disable
On 04/29/2014 04:34 PM, Eric Anholt wrote:
[snip]
> diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> index 4222fa8..053612e 100644
> --- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> +++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> @@ -804,9 +804,
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);
> - if (image->region == NULL) {
> - f
On 04/29/2014 04:34 PM, Eric Anholt wrote:
[snip]
> @@ -319,13 +319,15 @@ gen7_update_texture_surface(struct gl_context *ctx,
> if (mt->array_spacing_lod0)
>surf[0] |= GEN7_SURFACE_ARYSPC_LOD0;
>
> - surf[1] = mt->region->bo->offset64 + mt->offset; /* reloc */
> + surf[1] = mt->bo
69 matches
Mail list logo
