On Sun, Mar 16, 2014 at 12:14:29AM +0100, Marek Skalický wrote:
> Hi,
> My name is Marek Skalický. I am 20 years old and I study Applied
> informatics at Masaryk university in Brno.
> And I am interested in GSoC project about implementing OpenCL Image
> Support into r600g/radeonsi.
>
> I would lik
Am 17.03.2014 21:55, schrieb Dieter Nützel:
Am 17.03.2014 18:59, schrieb Benjamin Bellec:
Hi,
Could you bisect?
It's under way...
Here we go:
/opt/mesa> git bisect good
Bisecting: 0 revisions left to test after this (roughly 1 step)
[6c3f5abc2dc99a904994fb41d6e48527ddcdf7de] mesa: add miss
Ilia Mirkin writes:
> Signed-off-by: Ilia Mirkin
Reviewed-by: Francisco Jerez
> Cc: "10.0 10.1"
> ---
> src/mesa/drivers/dri/nouveau/nouveau_fbo.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
> b/src/mesa/drivers/dri/
There are a lot of different pci ids supported by nouveau, and more are
added all the time. The relevant distinguisher between drivers is the
chipset id.
Signed-off-by: Ilia Mirkin
Reviewed-by: Emil Velikov
Cc: "10.1"
---
This has, again, been tested on NV96 and NV05.
v3 -> v4:
- remove is_n
Kenneth Graunke writes:
> Hello,
>
> This series adds support for pull constants in SIMD16 mode. By the end
> of the series, shader-db gains 78 extra SIMD16 programs, and the net
> code change is -39 lines. In short:
>
> better living through deleting code.
>
> Most of the work in this seri
On Mon, Mar 17, 2014 at 7:11 PM, Emil Velikov wrote:
> On 17/03/14 22:23, Ilia Mirkin wrote:
>> There are a lot of different pci ids supported by nouveau, and more are
>> added all the time. The relevant distinguisher between drivers is the
>> chipset id.
>>
>> Signed-off-by: Ilia Mirkin
>> Cc: "
On 17/03/14 22:23, Ilia Mirkin wrote:
> There are a lot of different pci ids supported by nouveau, and more are
> added all the time. The relevant distinguisher between drivers is the
> chipset id.
>
> Signed-off-by: Ilia Mirkin
> Cc: "10.1"
> ---
>
> Tested with additional prints thrown in to
On Mon, Mar 17, 2014 at 6:23 PM, Ilia Mirkin wrote:
> There are a lot of different pci ids supported by nouveau, and more are
> added all the time. The relevant distinguisher between drivers is the
> chipset id.
>
> Signed-off-by: Ilia Mirkin
> Cc: "10.1"
> ---
>
> Tested with additional prints
There are a lot of different pci ids supported by nouveau, and more are
added all the time. The relevant distinguisher between drivers is the
chipset id.
Signed-off-by: Ilia Mirkin
Cc: "10.1"
---
Tested with additional prints thrown in to make sure that the right chipset id
is detected, etc. Te
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Mon, Mar 17, 2014 at 6:01 PM, Eric Anholt wrote:
> Ilia Mirkin writes:
>
>> On Mon, Mar 17, 2014 at 2:42 PM, Ilia Mirkin wrote:
>>> There are a lot of different pci ids supported by nouveau, and more are
>>> added all the time. The relevant distinguisher between drivers is the
>>> chipset id.
On 17 March 2014 14:54, Eric Anholt wrote:
> ---
> src/mesa/drivers/dri/i965/brw_draw_upload.c | 9 -
> 1 file changed, 9 deletions(-)
>
For future cross-referencing it would be nice to mention the SHA of Marek's
change in the commit message.
>
> diff --git a/src/mesa/drivers/dri/i965
Ilia Mirkin writes:
> On Mon, Mar 17, 2014 at 2:42 PM, Ilia Mirkin wrote:
>> There are a lot of different pci ids supported by nouveau, and more are
>> added all the time. The relevant distinguisher between drivers is the
>> chipset id.
>>
>> Signed-off-by: Ilia Mirkin
>> Cc: "10.1"
>> ---
>>
Kenneth Graunke writes:
> Register sets depend on the particular hardware generation, but don't
> depend on anything in the actual OpenGL context. Computing them is
> fairly expensive, and they take up a large amount of memory. Putting
> them in the screen allows us to compute/allocate them onc
---
src/mesa/drivers/dri/i965/brw_draw_upload.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c
b/src/mesa/drivers/dri/i965/brw_draw_upload.c
index d42c074..d08e56a 100644
--- a/src/mesa/drivers/dri/i965/brw_draw_upload.c
+++ b/src/mesa/driv
On Mon, Mar 17, 2014 at 2:42 PM, Ilia Mirkin wrote:
> There are a lot of different pci ids supported by nouveau, and more are
> added all the time. The relevant distinguisher between drivers is the
> chipset id.
>
> Signed-off-by: Ilia Mirkin
> Cc: "10.1"
> ---
>
> I haven't tested this on real
---
src/mesa/drivers/dri/i965/brw_blorp.cpp | 1 -
src/mesa/drivers/dri/i965/brw_context.h | 9 -
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 27 ---
src/mesa/drivers/dri/i965/intel_batchbuffer.h | 1 -
4 files changed, 38 deletions(-)
diff --git
This one saves about 2MB peak allocation in glsl-fs-algebraic-add-add-1,
with no performance difference on timing short shader-db runs (n=9/10,
warmup outlier removed).
---
src/mesa/program/register_allocate.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/src/me
Series is
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Kenneth Graunke writes:
> This isn't the GL API, so there's no reason to use GLboolean.
>
> Using bool is safer: any non-zero value is treated as "true". When
> converting a value to a GLboolean, all but the low byte is discarded,
> which means that values like 256 will be incorrectly rendered a
Register sets depend on the particular hardware generation, but don't
depend on anything in the actual OpenGL context. Computing them is
fairly expensive, and they take up a large amount of memory. Putting
them in the screen allows us to compute/allocate them once for all
contexts, saving both ti
To emphasize that the result is floating point 1.0 or 0.0, to match
other opcodes like SLE and SEQ.
---
src/gallium/docs/source/tgsi.rst | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
OK, I just looked at the state tracker now. I forgot that we checked
for the fallback there. We can revisit this if there are any issues.
Reviewed-by: Brian Paul
-Brian
On 03/17/2014 12:03 PM, Marek Olšák wrote:
No, I didn't, but st/mesa doesn't call u_gen_mipmap if the format
isn't suppor
On 03/17/2014 02:32 PM, Kenneth Graunke wrote:
This is a little easier to read.
Signed-off-by: Kenneth Graunke
---
src/mesa/program/register_allocate.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/mesa/program/register_allocate.c
b/src/mesa/program/
Am 17.03.2014 18:59, schrieb Benjamin Bellec:
Hi,
Could you bisect?
It's under way...
Or provide an easy way to build ogl-samples!
There was a post on dri-devel 've used.
Bug tracker look, here:
Bug 74717 - r600g: 'invalid read' linking geometry shader
https://bugs.freedesktop.org/show_bug
This should use 1/8 the memory.
Signed-off-by: Kenneth Graunke
---
src/mesa/program/register_allocate.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
Sadly, this does increase the runtime of
$ piglit-run.py -p gbm -c tests/gpu -t glsl-1.20/execution
by 0.44175 seconds +
This isn't the GL API, so there's no reason to use GLboolean.
Using bool is safer: any non-zero value is treated as "true". When
converting a value to a GLboolean, all but the low byte is discarded,
which means that values like 256 will be incorrectly rendered as false.
Done via the following vi
This is a little easier to read.
Signed-off-by: Kenneth Graunke
---
src/mesa/program/register_allocate.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/mesa/program/register_allocate.c
b/src/mesa/program/register_allocate.c
index edde730..c763b96 100644
-
Hi all,
I'm working on the KHR_debug for OpenGL ES junior job. I recently
submitted patches to allow the piglit tests to be enabled in GLES
contexts as well.
Now I want to work on the src/mapi/glapi/gen/es_EXT.xml file. Recently
I saw a patch that moved the KHR_debug extension to a include type of
There are a lot of different pci ids supported by nouveau, and more are
added all the time. The relevant distinguisher between drivers is the
chipset id.
Signed-off-by: Ilia Mirkin
Cc: "10.1"
---
I haven't tested this on real hardware yet, but perhaps this is a little less
hacky than the former
GLSL 1.50 spec says:
"If gl_FragCoord is redeclared in any fragment shader in a program,
it must be redeclared in all the fragment shaders in that
program that have a static use gl_FragCoord. All redeclarations of
gl_FragCoord in all fragment shaders in a single program must
have
Link error conditions added in previous patch are equally applicable
to GL_ARB_fragment_coord_conventions implementation. Extension's spec
says:
"If gl_FragCoord is redeclared in any fragment shader in a program,
it must be redeclared in all the fragment shaders in that program
that have
GLSL 1.50 spec says:
"If gl_FragCoord is redeclared in any fragment shader in a program,
it must be redeclared in all the fragment shaders in that
program that have a static use gl_FragCoord. All redeclarations of
gl_FragCoord in all fragment shaders in a single program must
have
Section 4.3.8.1, page 39 of GLSL 1.50 spec says:
"Within any shader, the first redeclarations of gl_FragCoord
must appear before any use of gl_FragCoord."
GLSL compiler should generate an error in following case:
vec4 p = gl_FragCoord;
layout(origin_upper_left) in vec4 gl_FragCoord;
void ma
Identified 2 bugs in patches 1/4 and 3/4. Will send out V4 of the series
with fixes.
On Fri, Feb 28, 2014 at 11:53 AM, Anuj Phogat wrote:
> GLSL 1.50 spec says:
>"If gl_FragCoord is redeclared in any fragment shader in a program,
> it must be redeclared in all the fragment shaders in th
On Mon, Mar 17, 2014 at 2:02 PM, Emil Velikov wrote:
> On 17/03/14 17:33, Ilia Mirkin wrote:
>> On Mon, Mar 17, 2014 at 1:12 PM, Emil Velikov
>> wrote:
>>> On 17/03/14 14:22, Ilia Mirkin wrote:
Signed-off-by: Ilia Mirkin
>>> Hi Ilia
>>>
>>> I'm not sure if a nouveau specific quirk is a nic
It would be good to know what's causing the error, so that we can rule
out the possibility that the test is wrong and Mesa is right.
Marek
On Mon, Mar 17, 2014 at 3:34 PM, Dieter Nützel wrote:
> Trying to run ogl-samples GL 3.2+ tests on my RV730 AGP.
>
> /opt/ogl-samples> ./build/release/gl-320
No, I didn't, but st/mesa doesn't call u_gen_mipmap if the format
isn't supported for rendering and that's the only call site. The
fallback has pretty much been dead code.
Marek
On Mon, Mar 17, 2014 at 4:42 PM, Brian Paul wrote:
> On 03/15/2014 11:17 AM, Marek Olšák wrote:
>>
>> From: Marek Olšá
On 17/03/14 17:33, Ilia Mirkin wrote:
> On Mon, Mar 17, 2014 at 1:12 PM, Emil Velikov
> wrote:
>> On 17/03/14 14:22, Ilia Mirkin wrote:
>>> Signed-off-by: Ilia Mirkin
>> Hi Ilia
>>
>> I'm not sure if a nouveau specific quirk is a nice idea, although the
>> only other solution is to add the "quir
Hi,
Could you bisect?
Or provide an easy way to build ogl-samples!
Regards.
Le 17/03/2014 15:34, Dieter Nützel a écrit :
> Trying to run ogl-samples GL 3.2+ tests on my RV730 AGP.
>
> /opt/ogl-samples> ./build/release/gl-320-primitive-sprite
> libGL: screen 0 does not appear to be DRI3 capable
>
I have sent an updated version of the patch to the mailing list.
I hope that the copyright header of si_dma.c is right - I copied it from
si_hw_context.c...
Ole
On Monday 17 March 2014, 02:33:35, Marek Olšák wrote:
> Thanks for doing this! I have some comments...
>
> 1) As of SI, the maximum su
Signed-off-by: Niels Ole Salscheider
---
src/gallium/drivers/r600/evergreen_hw_context.c | 2 +-
src/gallium/drivers/r600/evergreen_state.c | 2 +-
src/gallium/drivers/r600/r600_hw_context.c | 12 +---
src/gallium/drivers/r600/r600_pipe.h| 1 -
src/gallium/drivers
This code is a slightly modified version of evergreen_dma_blit (and
evergreen_dma_copy as well as evergreen_dma_copy_tile).
It would be nice to share some of the code in the long term.
I have reused some "cik"-prefixed functions that also return the right
value for SI. I am not sure if they should
On Mon, Mar 17, 2014 at 1:12 PM, Emil Velikov wrote:
> On 17/03/14 14:22, Ilia Mirkin wrote:
>> Signed-off-by: Ilia Mirkin
> Hi Ilia
>
> I'm not sure if a nouveau specific quirk is a nice idea, although the
> only other solution is to add the "quirk" in the driver_map table.
Meh, I don't see wha
Am 15.03.2014 18:17, schrieb Marek Olšák:
> From: Marek Olšák
>
> This is needed by _mesa_generate_mipmap.
>
> This adds an array of pipe_transfers to st_texture_image. Each transfer is
> for mapping a single layer. It's ugly, but at least _mesa_generate_mipmap
> works for array textures.
> ---
On Mon, Mar 17, 2014 at 03:36:37PM +, Dorrington, Albert wrote:
> I'm curious if there is any way to reset/restart the video card via Mesa or
> the libdrm drivers?
>
> I'm currently doing development against the OpenCL drivers, and getting the
> video card into a state where is will not resp
On 17/03/14 14:22, Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin
Hi Ilia
I'm not sure if a nouveau specific quirk is a nice idea, although the
only other solution is to add the "quirk" in the driver_map table.
> ---
> include/pci_ids/pci_id_driver_map.h | 1 -
> src/loader/loader.c
On 17/03/14 15:36, Dorrington, Albert wrote:
> I'm curious if there is any way to reset/restart the video card via Mesa or
> the libdrm drivers?
>
> I'm currently doing development against the OpenCL drivers, and getting the
> video card into a state where is will not respond.
> The only way I c
On Mon, Mar 17, 2014 at 11:36 AM, Dorrington, Albert
wrote:
> I'm curious if there is any way to reset/restart the video card via Mesa or
> the libdrm drivers?
>
>
>
> I'm currently doing development against the OpenCL drivers, and getting the
> video card into a state where is will not respond.
>
It's probably enough, indeed. (With "ctx != EGL_NO_CONTEXT &&" instead of
"ctx &&")
--
Beren Minor
On Mon, Mar 17, 2014 at 3:30 AM, Chia-I Wu wrote:
> On Sun, Mar 16, 2014 at 5:20 AM, Beren Minor
> wrote:
> > EGL 1.4 Specification says that
> > eglMakeCurrent(display, EGL_NO_SURFACE, EGL_NO_S
On 03/15/2014 11:17 AM, Marek Olšák wrote:
From: Marek Olšák
This is needed by _mesa_generate_mipmap.
This adds an array of pipe_transfers to st_texture_image. Each transfer is
for mapping a single layer. It's ugly, but at least _mesa_generate_mipmap
works for array textures.
---
src/mesa/st
On 03/15/2014 11:17 AM, Marek Olšák wrote:
From: Marek Olšák
The last changes to it are from 2008 and 2009.
It doesn't support most texture formats and some texture targets.
Nobody can possibly be using this.
Have you tested softpipe/llvmpipe with this change?
-Brian
___
I'm curious if there is any way to reset/restart the video card via Mesa or the
libdrm drivers?
I'm currently doing development against the OpenCL drivers, and getting the
video card into a state where is will not respond.
The only way I can get things cleaned up is by rebooting my Linux box, bu
On 03/16/2014 02:52 PM, Alexander von Gluck IV wrote:
On 01/10/2014 07:40 PM, Ian Romanick wrote:
From: Ian Romanick
No driver uses them. They will just be annoying in future patches.
Signed-off-by: Ian Romanick
---
src/mesa/drivers/dri/i915/intel_context.c | 15 ++-
src/mes
Trying to run ogl-samples GL 3.2+ tests on my RV730 AGP.
/opt/ogl-samples> ./build/release/gl-320-primitive-sprite
libGL: screen 0 does not appear to be DRI3 capable
libGL: pci id for fd 4: 1002:9495, driver r600
libGL: OpenDriver: trying /usr/lib/dri/updates/tls/r600_dri.so
libGL: OpenDriver: tr
Signed-off-by: Ilia Mirkin
Cc: "10.0 10.1"
---
src/mesa/drivers/dri/nouveau/nouveau_fbo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
b/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
index ae50fe0..6c479f5 100644
--- a/src/mesa/dr
On Mon, Mar 17, 2014 at 9:30 AM, Ilia Mirkin wrote:
> Hello,
>
> Starting with
>
> commit 7bd95ec437a5b1052fa17780a9d66677ec1fdc35
> Author: Eric Anholt
> Date: Thu Jan 23 10:21:09 2014 -0800
>
> dri2: Trust our own driver name lookup over the server's.
>
> This allows Mesa to choose to
Signed-off-by: Ilia Mirkin
---
include/pci_ids/pci_id_driver_map.h | 1 -
src/loader/loader.c | 25 +++--
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/include/pci_ids/pci_id_driver_map.h
b/include/pci_ids/pci_id_driver_map.h
index db9e07f..
This reverts commit d9b983519c63b9072677364a6e399d213a1855e5.
Unfortunately it seems like rpath is evaluated before LD_LIBRARY_PATH,
so this breaks e.g. stream, as well as any other user of that env var,
if the llvm path happens to be where other libs also reside.
Bugzilla: https://bugs.freedeskt
Hello,
Starting with
commit 7bd95ec437a5b1052fa17780a9d66677ec1fdc35
Author: Eric Anholt
Date: Thu Jan 23 10:21:09 2014 -0800
dri2: Trust our own driver name lookup over the server's.
This allows Mesa to choose to rename driver .sos (or split drivers),
without needing a flag day
Hi Ander,
Some comments inline.
And I have some further thinking about current GBM support, which is tied
to specific implementation closely, although the GBM APIs are quite
independent from mesa. I have some idea below to make GBM a generic
solution. I'm not sure if anybody else in the community
Signed-off-by: Petri Latvala
---
src/mesa/drivers/dri/i965/intel_extensions.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
b/src/mesa/drivers/dri/i965/intel_extensions.c
index 2a68758..5dbd1e6 100644
--- a/src/mesa/drivers/dr
Using the existing driver hooks made for AMD_performance_monitor, implement
INTEL_performance_query functions.
v2: Whitespace changes.
Signed-off-by: Petri Latvala
---
src/mesa/main/performance_monitor.c | 472
1 file changed, 431 insertions(+), 41 deletions
Signed-off-by: Petri Latvala
---
src/mesa/main/tests/enum_strings.cpp | 18 ++
1 file changed, 18 insertions(+)
diff --git a/src/mesa/main/tests/enum_strings.cpp
b/src/mesa/main/tests/enum_strings.cpp
index 3795700..d16eb36 100644
--- a/src/mesa/main/tests/enum_strings.cpp
+++ b
Second revision for patch series that implements the
INTEL_performance_query extension. Changes: Import glext.h instead of
adding definitions to gl.h, fix whitespace changes caused by folding
into the wrong commit.
Petri Latvala (6):
mesa: update glext.h to version 20140313
Regenerate gl_mangl
Like AMD_performance_monitor, this extension provides an interface for
applications (and OpenGL-based tools) to access GPU performance
counters. Since the exact performance counters available vary between
vendors and hardware generations, the extension provides an API the
application can use to get
---
include/GL/glext.h | 82 ++
1 file changed, 76 insertions(+), 6 deletions(-)
diff --git a/include/GL/glext.h b/include/GL/glext.h
index 62bae4c..a626580 100644
--- a/include/GL/glext.h
+++ b/include/GL/glext.h
@@ -6,7 +6,7 @@ extern "C" {
#
Am 17.03.2014 03:55, schrieb Kusanagi Kouichi:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75699
Signed-off-by: Kusanagi Kouichi
---
src/gallium/state_trackers/vdpau/surface.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/vdpau/surfa
https://bugs.freedesktop.org/show_bug.cgi?id=76252
Priority: medium
Bug ID: 76252
Assignee: mesa-dev@lists.freedesktop.org
Summary: Dynamic loading/unloading of opengl32.dll results in a
deadlock
Severity: major
Classific
69 matches
Mail list logo
