Am 19.09.2013 20:43, schrieb Zack Rusin:
> Unfortunately d3d10 requires a lot higher precision (e.g.
> wgf11clipping tests for it). The smallest number of precision
> bits with which it passes is 8. That means that we need to
> decrease the maximum length of an edge that we can handle without
> sub
Am 19.09.2013 20:43, schrieb Zack Rusin:
> Compress empty triangles (don't emit more than one in a row) and
> never emit empty triangles if we already generated a triangle
> covering a non-null area. We can't skip all null-triangles
> because c_primitives expects ones that were generated from verti
https://bugs.freedesktop.org/show_bug.cgi?id=69202
--- Comment #4 from Matt Turner ---
*** Bug 69592 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
me
https://bugs.freedesktop.org/show_bug.cgi?id=69592
Matt Turner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=69592
Priority: medium
Bug ID: 69592
Keywords: regression
CC: matts...@gmail.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: piglit fs-mix-vec2-vec2-bvec2 regression
Se
This appears in Volume 1 Part 1 of the Sandybridge PRM on page 48.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_defines.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index e283805..b1
Ironlake's counters are always enabled; userspace can simply send a
MI_REPORT_PERF_COUNT packet to take a snapshot of them. This makes it
easy to implement.
The counters are documented in the source code for the intel-gpu-tools
intel_perf_counters utility.
v2: Adjust for core data structure chan
This 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 the names, types, and
minimum/maximum
Hello,
After a long hiatus, here are updated AMD_performance_monitor patches.
I've reworked the core data structures significantly. Counter lists
are now stored in the group objects, rather than as a single global list,
which means counter IDs don't need to be globally unique. Also, instead
of
Am 19.09.2013 20:43, schrieb Zack Rusin:
> We need to count the clipper primitives before the rasterizer
> discards one it considers to be null.
>
> Signed-off-by: Zack Rusin
> ---
> src/gallium/drivers/llvmpipe/lp_setup_tri.c | 13 ++---
> 1 file changed, 6 insertions(+), 7 deletions(-)
https://bugs.freedesktop.org/show_bug.cgi?id=69589
--- Comment #1 from Ian Romanick ---
It seems that ES3 and desktop GL specify different errors. Hurrah for
convergence. :(
The text quoted by this test appears in both the 3.2 spec and the 3.1 spec. I
have posted patches to the piglit list tha
Following idr's suggestion I limited the scope of my GSoC project to just
the functionality of GL_EXT_direct_state_access that isn't removed in
OpenGL 3.1+, so the extension is only advertised in core contexts.
It seems like the series is way too big to just send to the list
immediately, but it's
I like this approach a lot... certainly a lot more than various
inheritance-based approaches that we had discussed before.
Patches 1, 2, 3, and 5 are
Reviewed-by: Ian Romanick
Patch 4 probably is too (with the comment addition that I suggested),
but I'd like to hear your thoughts about the perf
On 09/18/2013 04:55 PM, Kenneth Graunke wrote:
> Previously, almost all classes didn't actually call their destructors,
> which is non-intuitive for C++ code. Setting them up to be called was
> somewhat of a pain, since it required defining a helper function.
>
> With the new macros, we can easil
Premature "send" strikes again...
On 09/19/2013 05:26 PM, Ian Romanick wrote:
> On 09/18/2013 04:55 PM, Kenneth Graunke wrote:
>> Previously, almost all classes didn't actually call their destructors,
>> which is non-intuitive for C++ code. Setting them up to be called was
>> somewhat of a pain,
On 09/18/2013 04:55 PM, Kenneth Graunke wrote:
> Most of our C++ classes define placement new and delete operators so we
> can do convenient allocation via:
>
>thing *foo = new(mem_ctx) thing(...)
>
> Currently, this is done via a lot of boilerplate. By adding simple
> macros to ralloc, we c
The compiler cannot find the Xlib.h in the installed system headers.
All supplied include directives point to inside the mesa module.
The X11_CFLAGS variable is undefined (not defined in config.status).
It appears the intent was to use X11_INCLUDES defined in configure.ac.
The Xlib.h file is not
The X11_CFLAGS variable is undefined (not defined in config.status).
It appears the intent was to use X11_INCLUDES defined in configure.ac.
It is used for building the code in the x11 subdir.
The build does not fail on this one as LIBDRM_CFLAGS happens to have
the inludedir value as the one for X1
The compiler cannot find the Xlib.h in the installed system headers.
All supplied include directives point to inside the mesa module.
The X11_CFLAGS variable is undefined (not defined in config.status).
It appears the intent was to use X11_INCLUDES defined in configure.ac.
The Xlib.h file is not
The X11_CFLAGS variable is undefined (not defined in config.status).
It appears the intent was to use X11_INCLUDES defined in configure.ac.
Gaetan Nadon (3):
gallium/targets/libgl-xlib: X11/Xlib.h: No such file or directory
gallium/state_trackers/egl: use X11_INCLUDES rather than X11_CFLAGS
https://bugs.freedesktop.org/show_bug.cgi?id=69589
Priority: medium
Bug ID: 69589
Keywords: regression
Assignee: mesa-dev@lists.freedesktop.org
Summary: [bisected] Piglit gl-3.2-draw-buffers-errors fails
Severity: normal
Classifica
On 09/18/2013 02:57 PM, Kenneth Graunke wrote:
On 09/15/2013 12:10 AM, Francisco Jerez wrote:
This patch introduces a pair of helper functions providing a common
implementation of the "new" and "delete" operators for all C++ classes
that are allocated by ralloc via placement new. The 'ralloc_ne
On 09/18/2013 02:55 PM, Kenneth Graunke wrote:
These classes declared a placement new operator, but didn't declare a
delete operator. Switching to the macro gives them a delete operator,
which probably is a good idea anyway.
This also eliminates a lot of boilerplate.
Signed-off-by: Kenneth Gra
Compress empty triangles (don't emit more than one in a row) and
never emit empty triangles if we already generated a triangle
covering a non-null area. We can't skip all null-triangles
because c_primitives expects ones that were generated from vertices
exactly at the clipping-plane, to be emitted.
On 15 September 2013 00:10, Francisco Jerez wrote:
> The maximum number of atomic buffer objects is somewhat arbitrary, we
> can change it in the future easily if it turns out it's not enough...
> ---
> src/mesa/drivers/dri/i965/brw_context.h | 17 +++--
> src/mesa/drivers/dri/i965/
Unfortunately d3d10 requires a lot higher precision (e.g.
wgf11clipping tests for it). The smallest number of precision
bits with which it passes is 8. That means that we need to
decrease the maximum length of an edge that we can handle without
subdivision by 4 bits. Abstracted the code a bit to ma
We need to count the clipper primitives before the rasterizer
discards one it considers to be null.
Signed-off-by: Zack Rusin
---
src/gallium/drivers/llvmpipe/lp_setup_tri.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_setup_tr
On 09/19/2013 10:46 AM, Gaetan Nadon wrote:
> On 13-09-18 09:41 PM, Kenneth Graunke wrote:
[snip]
>> This looks good to me. There are a couple of other instances of
>> X11_CFLAGS in the codebase as well. Presumably those need to be changed
>> as well?
>
> These did not break the build for me. I
On 15 September 2013 00:10, Francisco Jerez wrote:
> And add Gen7 implementation.
> ---
> src/mesa/drivers/dri/i965/brw_context.h | 7 +
> src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 35
> +++
> 2 files changed, 37 insertions(+), 5 deletions(-)
>
> diff
On 15 September 2013 00:10, Francisco Jerez wrote:
> ---
> src/glsl/Makefile.sources | 1 +
> src/glsl/link_atomics.cpp | 190
> ++
> src/glsl/linker.cpp | 15
> src/glsl/linker.h | 7 ++
> 4 files changed, 213 insertions(+)
>
On 13-09-18 09:41 PM, Kenneth Graunke wrote:
> On 09/17/2013 12:46 PM, Gaetan Nadon wrote:
>> egl_glx.c:40:22: fatal error: X11/Xlib.h: No such file or directory
>>
>> The compiler cannot find the Xlib.h in the installed system headers.
>> All supplied include directives point to inside the mesa mo
Kenneth Graunke writes:
> These classes declared a placement new operator, but didn't declare a
> delete operator. Switching to the macro gives them a delete operator,
> which probably is a good idea anyway.
>
> This also eliminates a lot of boilerplate.
>
> Signed-off-by: Kenneth Graunke
> d
On 19 September 2013 00:54, Rogovin, Kevin wrote:
> Hello all,
>
> ** **
>
> I thank all those that have answered my questions, I still have a few
> more. Here goes.
>
> ** **
>
> I saw that geometry shaders were landed recently in some form. My
> questions are:
>
> **· **W
From: Roland Scheidegger
Technically without seamless filtering enabled GL allows any wrap mode, which
made sense when supporting true borders (can get seamless effect with border
and CLAMP_TO_BORDER), but gallium doesn't support borders and d3d9 requires
wrap modes to be ignored and it's a pain
Patches 3 & 4 are
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.o
Sounds good to me. Thanks.
Jose
- Original Message -
> From: Roland Scheidegger
>
> Technically without seamless filtering enabled GL allows any wrap mode, which
> made sense when supporting true borders (can get seamless effect with border
> and CLAMP_TO_BORDER), but gallium doesn't su
---
src/gallium/drivers/radeonsi/radeonsi_shader.c | 32 ++
1 file changed, 23 insertions(+), 9 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c
b/src/gallium/drivers/radeonsi/radeonsi_shader.c
index 867a385..7e3ac5a 100644
--- a/src/gallium/driver
https://bugs.freedesktop.org/show_bug.cgi?id=54763
Eero Tamminen changed:
What|Removed |Added
CC||eero.t.tammi...@intel.com
--
You are re
---
src/gallium/drivers/radeonsi/radeonsi_shader.c | 41 ++
src/gallium/drivers/radeonsi/si_state.c| 3 +-
2 files changed, 17 insertions(+), 27 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c
b/src/gallium/drivers/radeonsi/radeonsi_shade
Cc: "9.2"
---
src/gallium/drivers/r600/r600_hw_context.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index b7c345a..e055d62 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
Cc: "9.2"
---
src/gallium/drivers/r600/r600_hw_context.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index d985af9..b7c345a 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
>
>
>
> Last question set and I do not know a good way to go about this. Right now
> the documentation of Mesa looks like to me to be in the code in comments;
> this is great when working on one area/zone, but really hard to get a global
> picture of Mesa. Given that I am trying to do just that, I
Hello all,
I thank all those that have answered my questions, I still have a few more.
Here goes.
I saw that geometry shaders were landed recently in some form. My questions are:
* What is the execution style of the geometry shader on i965? (i.e. the
fragment shader is invoked 8 frag
43 matches
Mail list logo
