I wanted to know if it would be possible for me to do the project if I am a
good coder in the C language but have never used OpenGL.If you would guide me
from were to read then I would definitely do that .
___
mesa-d
Hi all
I am interested to participate in GSoC this year in X.org. I have gone
through the proposed ideas and I am interested in working on finding common
patterns in real GLSL shaders.
I understand that this is a datamining problem where we mine patterns in
the shaders. So, how do I go ahead now?
Assuming this matched your make-dist-1 branch,
Series Reviewed-by: Jordan Justen
On Thu, Apr 11, 2013 at 4:29 PM, Matt Turner wrote:
> For the sake of consistency.
>
> Tested-by: Emil Velikov
> Reviewed-and-Tested-by: Andreas Boll
> ---
> src/glx/apple/Makefile | 2 +-
> src/ma
The issue with SOA execution and end_primitive opcode is that it
can be executed both when we haven't emitted any vertices, in
which case we don't want to emit an empty primitive, and when
the execution mask is zero and the execution should be skipped. We
handled only the latter of those conditions
This is a basic implementation of the pipeline statistics in the
draw module. The interface is similar to the stream output statistics
and also requires that the callers explicitly enable it.
Included is the implementation of the interface in llvmpipe and
softpipe. Only softpipe enables the pipelin
configure still uses it to print the enabled winsys.
Tested-by: Emil Velikov
Reviewed-and-Tested-by: Andreas Boll
---
Since last time:
- Rebase and add freedreno.
configure.ac | 38 +-
src/gallium/winsys/Makefile.am| 66 ++
configure still uses it to print the enabled targets.
Tested-by: Emil Velikov
Reviewed-and-Tested-by: Andreas Boll
---
Since last time:
- Rebase and add freedreno.
configure.ac| 2 +-
src/gallium/targets/Makefile.am | 152 +++-
2 fil
And don't build it from other Makefiles. That's awful, and breaks
distclean.
Tested-by: Emil Velikov
Reviewed-and-Tested-by: Andreas Boll
---
configure.ac | 8
src/gallium/targets/opencl/Makefile.am | 3 ---
src/gallium/tests/trivial/Makefile.am | 4
3 f
Tested-by: Emil Velikov
Reviewed-and-Tested-by: Andreas Boll
---
Since last time:
- Rebase and add freedreno.
configure.ac| 31 +++
src/gallium/drivers/Makefile.am | 84 -
src/gallium/targets/pipe-loader/Makefile
configure still uses it to print the enabled state trackers.
Tested-by: Emil Velikov
Reviewed-and-Tested-by: Andreas Boll
---
configure.ac | 45 +++
src/gallium/state_trackers/Makefile.am | 65 --
2 files changed, 75
Tested-by: Emil Velikov
Reviewed-and-Tested-by: Andreas Boll
---
configure.ac | 9 ++---
src/mesa/Makefile.am | 14 +-
src/mesa/drivers/Makefile.am | 22 --
3 files changed, 15 insertions(+), 30 deletions(-)
delete mode 100644 src/mes
Neither are used in Makefile.ams.
Tested-by: Emil Velikov
Reviewed-and-Tested-by: Andreas Boll
---
configure.ac | 2 --
1 file changed, 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 299007d..9eec334 100644
--- a/configure.ac
+++ b/configure.ac
@@ -784,7 +784,6 @@ fi
AC_SUBST([
It's always constant anyway.
Tested-by: Emil Velikov
Reviewed-and-Tested-by: Andreas Boll
---
configure.ac| 4
src/Makefile.am | 4 +++-
src/gallium/Makefile.am | 22 --
3 files changed, 3 insertions(+), 27 deletions(-)
delete mode 100644 src/gall
Tested-by: Emil Velikov
Reviewed-and-Tested-by: Andreas Boll
---
Since last time:
- Stop building src/glx for xlib-glx, as noticed out by Eric and Andreas.
(Relies on the fact that $enable_dri and $enable_xlib_glx are mutually
exclusive)
configure.ac| 21 +++--
A step toward working make dist/distcheck.
Tested-by: Emil Velikov
Reviewed-and-Tested-by: Andreas Boll
---
configure.ac | 37 -
src/Makefile.am | 30 +++---
src/mapi/Makefile.am | 42 ++
For the sake of consistency.
Tested-by: Emil Velikov
Reviewed-and-Tested-by: Andreas Boll
---
src/glx/apple/Makefile | 2 +-
src/mapi/glapi/Makefile.am | 4 +-
src/mapi/glapi/Makefile.sources | 19 ++
src/mapi/glapi/sources.mak | 19 --
src/mapi/mapi/Mak
Change egl_g3d_wl_drm_common_query_buffer() to use boolean/int rather than
EGLBoolean/EGLint, based on the interface in native_wayland_bufmgr.h,
Resolves type conversion warnings spotted by gcc
x11/native_dri2.c:892:1: warning: initialization from incompatible pointer
type[enabled by default]
};
Remove extra chipset check during nvc0_screen_create
Set the class_3d after the object is created
Signed-off-by: Emil Velikov
---
src/gallium/drivers/nv50/nv50_screen.c | 2 +-
src/gallium/drivers/nvc0/nvc0_screen.c | 12 +---
2 files changed, 2 insertions(+), 12 deletions(-)
diff --gi
Pointed out by gcc
nve4_compute.c: In function 'nve4_launch_grid':
nve4_compute.c:511:7: warning: 'ret' may be used uninitialized in this function
[-Wmaybe-uninitialized]
if (ret)
^
Signed-off-by: Emil Velikov
---
src/gallium/drivers/nvc0/nve4_compute.c | 2 +-
1 file changed, 1 ins
Exit gracefully rather than trying to create a random object, whenever the
chipset is unknown
Signed-off-by: Emil Velikov
---
src/gallium/drivers/nvc0/nve4_compute.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nvc0/nve4_compute.c
b/src/gallium/drivers
As otherwise it is unused - pointed out by gcc
nve4_compute.c:586:20: warning: 'nve4_cache_split_name' defined but not used
[-Wunused-function]
static const char *nve4_cache_split_name(unsigned value)
^
Signed-off-by: Emil Velikov
---
src/gallium/drivers/nvc0/nve4_compute.
For debug build we'll hit the assert, for release we are going to emit random
data
as subOp is used uninitilised. Spotted by gcc
codegen/nv50_ir_emit_nv50.cpp: In member function 'void
nv50_ir::CodeEmitterNV50::emitATOM(const nv50_ir::Instruction*)':
codegen/nv50_ir_emit_nv50.cpp:1554:12: warnin
Here is a short patchset that handles most of the compile warnings for my
gallium/nouveau 'release' build.
The commit messages may be rather silly but I was running out of ideas
what to put :)
Anyway the first five patches are nv50,nvc0 related, whereas the last one
changes a egl/wayland funct
Add a note to update PACKAGE_VERSION for Android and scons builds
Signed-off-by: Emil Velikov
---
docs/devinfo.html | 2 ++
1 file changed, 2 insertions(+)
diff --git a/docs/devinfo.html b/docs/devinfo.html
index 5c03344..7176824 100644
--- a/docs/devinfo.html
+++ b/docs/devinfo.html
@@ -197,6
Signed-off-by: Emil Velikov
---
docs/relnotes.html | 3 +++
1 file changed, 3 insertions(+)
diff --git a/docs/relnotes.html b/docs/relnotes.html
index 049a979..819d2ce 100644
--- a/docs/relnotes.html
+++ b/docs/relnotes.html
@@ -22,6 +22,7 @@ The release notes summarize what's new or changed in
As suggested by Jose, here is a short patchset that handles the
initial stage of beating some structure into the docs directory
* All the release notes (both text and html) have been moved to
relnotes/, with filenames indicating the version only
* Mesa/WL extensions have been moved to specs/, incl
On Thu, Apr 11, 2013 at 2:00 PM, Kenneth Graunke wrote:
> 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
Am 11.04.2013 22:52, schrieb Zack Rusin:
>> - Original Message -
>>> - Original Message -
Ah.. This indeed rings a bell. I don't recall the details but I'm pretty
sure
I was against dual semantics. And the fact that this problem is again
showing its ugly head is
https://bugs.freedesktop.org/show_bug.cgi?id=63435
--- Comment #1 from post+...@ralfj.de ---
I totally forgot my software and hardware specs:
I am using Debian testing with a self-compiled vanilla 3.8.5 kernel. Other than
that, I use the distribution packages. My GPU is the one built-in my Core
i5
- Original Message -
> > - Original Message -
> > > - Original Message -
> > > > Ah.. This indeed rings a bell. I don't recall the details but I'm
> > > > pretty
> > > > sure
> > > > I was against dual semantics. And the fact that this problem is again
> > > > showing its
Ironlake's counters are always enabled; userspace can simply send a
MI_REPROT_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.
Signed-off-by: Kenneth Graunke
---
sr
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
Matt Turner writes:
> Also change if (shader) to if (prog) for consistency.
If the _mesa_problem is pulled out of the "if (prog)" in both patches
(since it doesn't rely on the program, and you'd want to know), then:
Reviewed-by: Eric Anholt
pgpDwZqCAcTWE.pgp
Description: PGP signature
__
Actually our svga driver seems to think that the IF opcode works like
that. Since it will translate it into a SVGA3DOP_IFC (which corresponds
to shader model 2 if_comp which compares to sources and specifies a
comparison function - my guess is this is what the unused
TGSI_OPCODE_IFC was meant for,
> - Original Message -
> > - Original Message -
> > > Ah.. This indeed rings a bell. I don't recall the details but I'm pretty
> > > sure
> > > I was against dual semantics. And the fact that this problem is again
> > > showing its ugly head is the proof of it.
> > >
> > > We reall
- Original Message -
> - Original Message -
> > Ah.. This indeed rings a bell. I don't recall the details but I'm pretty
> > sure
> > I was against dual semantics. And the fact that this problem is again
> > showing its ugly head is the proof of it.
> >
> > We really should have
- Original Message -
> Ah.. This indeed rings a bell. I don't recall the details but I'm pretty sure
> I was against dual semantics. And the fact that this problem is again
> showing its ugly head is the proof of it.
>
> We really should have two IF opcodes. And the state tracker should ch
SM3 hardware does have NaNs. Anyway, I'd like to have this SM3-specific
behavior of TGSI_OPCODE_IF properly documented. We already generate
different TGSI code for SM3 and SM4+ and there'll be much more differences
in how things are done in the future (e.g. temporaries could be used in
place of add
Ah.. This indeed rings a bell. I don't recall the details but I'm pretty sure I
was against dual semantics. And the fact that this problem is again showing its
ugly head is the proof of it.
We really should have two IF opcodes. And the state tracker should choose which
one it wants.
Jose
> What about drivers without integer support? The IF instruction should have 2
> definitions: one for the drivers which support PIPE_SHADER_CAP_INTEGERS, and
> the other one for those which don't. Obviously, there is no way to change
> the behavior of the IF opcode if you only have floats.
I think
Everything emitting those opcodes always assumed this is some sort of
boolean until now, so treating them as floats always was sketchy. Note
that the differences to treating them as uints or floats for comparisons
to zero isn't large, it's the same for everything except -0.0 and NaNs,
and I suspect
What about drivers without integer support? The IF instruction should have
2 definitions: one for the drivers which support PIPE_SHADER_CAP_INTEGERS,
and the other one for those which don't. Obviously, there is no way to
change the behavior of the IF opcode if you only have floats.
Marek
On Thu,
On Thu, Apr 11, 2013 at 11:06 AM, Eric Anholt wrote:
> I got tired of freaking out a little every time I built my release tree
> because of compile warnings. All but the last 2 seemed like pretty clean
> fixes to me.
>
> And then there's the first patch, which is unrelated but I found while
> try
We don't want to store this thing in the class, and we do need the
definition to be at the top of the function and held onto until the end
here, so there's not much to do besides (void) reference it.
---
src/mesa/drivers/dri/i965/brw_fs.cpp |1 +
1 file changed, 1 insertion(+)
diff --git a/sr
This was copy and pasted from can_reswizzle_dst(), and we can just fold it
in instead to avoid the warning.
---
src/mesa/drivers/dri/i965/brw_vec4.cpp |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_ve
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index 772c393..f9768df 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap
It's used in an assert, but we have this as a member of the class anyway.
---
src/mesa/drivers/dri/i965/brw_fs.cpp |1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 88aa695..c945617 100644
--- a/src/mesa/drivers
I think this actually clarifies what's going on in the asserts a bit,
given how many regions we've got floating around.
---
src/mesa/drivers/dri/i965/brw_misc_state.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
b/src/mesa
I don't see a sensible value to use in this path, but we shouldn't ever
hit this outside of developer new-texture-target enabling.
---
src/mesa/drivers/dri/i965/brw_lower_texture_gradients.cpp |1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/brw_lower_texture_gradie
We assert that failure doesn't happen, but it fixes a warning in the
release build and it would at least give working behavior for a user by
falling back to the normal texsubimage path.
---
src/mesa/drivers/dri/intel/intel_tex_subimage.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
This was silly -- checking that we didn't overflow the array by dividing
the array size by 2 and then multiplying it back up by 2.
---
src/mesa/drivers/dri/intel/intel_context.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/s
Asserts don't stop execution in release builds, so we would continue on to
use an uninitialized format value. Just take the failure path, which
appears to continue up the call stack for a while.
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c |2 +-
1 file changed, 1 insertion(+), 1 deleti
This fixes unused variable warnings in the release build, and should be
more useful if it ever triggers.
---
src/mesa/drivers/dri/intel/intel_blit.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_blit.c
b/src/mesa/drivers/dri/intel/i
We have this support for firsthalf/sechalf instructions, which would be
called in the !has_compr4 (aka original gen4) 16-wide case. We currently
only support 16-wide for gen5+, so we weren't tripping over this, but it
would have been a problem if we ever try to enable it.
---
src/mesa/drivers/dri
The call has no side effects, and moving it into the assert cleans up a
compile warning in the release build.
---
src/mesa/drivers/dri/i915/i830_vtbl.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i830_vtbl.c
b/src/mesa/drivers/dri/i915/i830
I got tired of freaking out a little every time I built my release tree
because of compile warnings. All but the last 2 seemed like pretty clean
fixes to me.
And then there's the first patch, which is unrelated but I found while
trying to figure out why register_coalesce() does something that
opt
---
src/mesa/drivers/dri/i965/brw_vec4.cpp |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index 4f7b8c0..6a2ce35 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/d
Also change if (shader) to if (prog) for consistency.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 12 +++-
src/mesa/drivers/dri/i965/brw_vec4.cpp |8 +---
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri
Am 11.04.2013 19:09, schrieb Zack Rusin:
> - Original Message -
>> Am 11.04.2013 05:20, schrieb Zack Rusin:
>>> As implemented in tgsi_exec they both test src operands on the bit
>>> level and don't do floating point comperisons as some thought.
>>> This documents them as such to avoid futu
- Original Message -
> Am 11.04.2013 05:20, schrieb Zack Rusin:
> > As implemented in tgsi_exec they both test src operands on the bit
> > level and don't do floating point comperisons as some thought.
> > This documents them as such to avoid future confusion and fixes
> > their implementat
On 10 April 2013 14:33, Ian Romanick wrote:
> On 04/10/2013 01:32 PM, Kenneth Graunke wrote:
>
>> On 04/09/2013 09:01 PM, Paul Berry wrote:
>>
>>> The comment above glsl_type::name claimed that it could sometimes be
>>> NULL. This was wrong--it is never NULL. Many error handling paths
>>> would
Am 11.04.2013 05:20, schrieb Zack Rusin:
> As implemented in tgsi_exec they both test src operands on the bit
> level and don't do floating point comperisons as some thought.
> This documents them as such to avoid future confusion and fixes
> their implementation in llvmpipe.
>
> Could gallium dri
Am 11.04.2013 05:20, schrieb Zack Rusin:
> As implemented in tgsi_exec they both test src operands on the bit
> level and don't do floating point comperisons as some thought.
> This documents them as such to avoid future confusion and fixes
> their implementation in llvmpipe.
>
> Could gallium dri
As implemented in tgsi_exec they both test src operands on the bit
level and don't do floating point comperisons as some thought.
This documents them as such to avoid future confusion and fixes
their implementation in llvmpipe.
Could gallium driver developers make sure that they're handling
those
https://bugs.freedesktop.org/show_bug.cgi?id=63435
Priority: medium
Bug ID: 63435
Assignee: mesa-dev@lists.freedesktop.org
Summary: [Regression since 9.0] Flickering in EGL OpenGL
full-screen window with swap interval 1
Sever
On 04/11/2013 02:08 AM, Marek Olšák wrote:
Here's the output:
creating vs ...
shader compilation status: OK
creating fs ...
shader compilation status: OK
thread #0 (0;0) : ref = 16608
thread #1 (1;0) : ref = 27873
thread #2 (0;1) : ref = 16608
thread #3 (1;1) : ref = 27877
results:
thread 0 (0
On Wed, Apr 10, 2013 at 11:04:22PM +0200, Vincent Lejeune wrote:
> ---
Could you add a comment explaining why export instructions are not
duplicable. With that change:
Reviewed-by: Tom Stellard
> lib/Target/R600/R600Instructions.td | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
On Wed, Apr 10, 2013 at 11:04:20PM +0200, Vincent Lejeune wrote:
> ---
Reviewed-by: Tom Stellard
> lib/Target/R600/AMDGPUAsmPrinter.cpp | 35 +--
> lib/Target/R600/AMDGPUAsmPrinter.h | 3 ++-
> 2 files changed, 35 insertions(+), 3 deletions(-)
>
> diff --git
2013/4/11 Christian König
> Am 11.04.2013 15:54, schrieb Andreas Boll:
>
> 2013/4/11 Christian König
>>
>> From: Christian König
>>>
>>> Separated from UVD patch for clarity.
>>>
>>> v2: sync with next tree for 3.10
>>>
>>> http://cgit.freedesktop.org/~**agd5f/linux/log/?h=drm-next-3.**10-wip
On Wed, Apr 10, 2013 at 11:04:21PM +0200, Vincent Lejeune wrote:
> ---
> lib/Target/R600/MCTargetDesc/R600MCCodeEmitter.cpp | 15 +--
> lib/Target/R600/R600Instructions.td| 8
> 2 files changed, 9 insertions(+), 14 deletions(-)
>
> diff --git a/lib/Target/R60
Am 11.04.2013 15:54, schrieb Andreas Boll:
2013/4/11 Christian König
From: Christian König
Separated from UVD patch for clarity.
v2: sync with next tree for 3.10
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.10-wip
Signed-off-by: Christian König
---
src/gallium/winsys/rade
https://bugs.freedesktop.org/show_bug.cgi?id=63078
post+...@ralfj.de changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #6 from post+...@r
2013/4/11 Christian König
> From: Christian König
>
> Separated from UVD patch for clarity.
>
> v2: sync with next tree for 3.10
>
> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.10-wip
>
> Signed-off-by: Christian König
> ---
> src/gallium/winsys/radeon/drm/radeon_drm_cs.c |
On Thu, Apr 11, 2013 at 9:39 AM, Christian König
wrote:
> From: Christian König
>
> Separated from UVD patch for clarity.
>
> v2: sync with next tree for 3.10
>
> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.10-wip
>
> Signed-off-by: Christian König
For the series:
Reviewed-by: A
Hopefully the last round for this patchset.
Since we now have a stable kernel interface I'm going to commit it this evening
if nobody objects.
Christian.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/lis
From: Christian König
Separated from UVD patch for clarity.
v2: sync with next tree for 3.10
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.10-wip
Signed-off-by: Christian König
---
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 11 +++
src/gallium/winsys/radeon/dr
Series looks good to me.
Jose
- Original Message -
> which means that our execution mask in GS is equal to 1 not 0xf.
>
> Signed-off-by: Zack Rusin
> ---
> src/gallium/auxiliary/tgsi/tgsi_exec.c | 30 +-
> 1 file changed, 17 insertions(+), 13 deletions(-)
---
src/gallium/auxiliary/hud/hud_fps.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/hud/hud_fps.c
b/src/gallium/auxiliary/hud/hud_fps.c
index 71cdfd0..80381f5 100644
--- a/src/gallium/auxiliary/hud/hud_fps.c
+++ b/src/gallium/auxiliary/hud/hud_fp
for the env var string not to be awfully long
v2: fix bug in indexing of "name"
---
src/gallium/auxiliary/hud/hud_context.c | 43 ---
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/src/gallium/auxiliary/hud/hud_context.c
b/src/gallium/auxiliary/hud/
---
src/gallium/auxiliary/hud/hud_context.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/hud/hud_context.c
b/src/gallium/auxiliary/hud/hud_context.c
index 4912b2a..eb7a67a 100644
--- a/src/gallium/auxiliary/hud/hud_context.c
+++ b/src/gallium/auxili
---
src/gallium/auxiliary/hud/hud_context.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/hud/hud_context.c
b/src/gallium/auxiliary/hud/hud_context.c
index 20115a5..4912b2a 100644
--- a/src/gallium/auxiliary/hud/hud_context.c
+++
for the env var string not to be awfully long
---
src/gallium/auxiliary/hud/hud_context.c | 39 ---
1 file changed, 20 insertions(+), 19 deletions(-)
diff --git a/src/gallium/auxiliary/hud/hud_context.c
b/src/gallium/auxiliary/hud/hud_context.c
index 983f057..20115a
---
src/gallium/drivers/r600/r600_pipe.c |2 +-
src/gallium/drivers/r600/r600_pipe.h |1 +
src/gallium/drivers/r600/r600_query.c | 95 +
src/gallium/drivers/r600/r600d.h |3 ++
4 files changed, 100 insertions(+), 1 deletion(-)
diff --git a/src/
---
src/gallium/drivers/r600/r600_pipe.c |2 +-
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 27 -
src/gallium/winsys/radeon/drm/radeon_winsys.h | 10 ++--
3 files changed, 13 insertions(+), 26 deletions(-)
diff --git a/src/gallium/drivers/r
---
src/gallium/drivers/r600/r600_buffer.c |7 +++
src/gallium/drivers/r600/r600_pipe.c|1 +
src/gallium/drivers/r600/r600_pipe.h|1 +
src/gallium/drivers/r600/r600_texture.c |8
4 files changed, 17 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_buf
---
src/gallium/drivers/r600/r600_pipe.c |1 +
src/gallium/drivers/r600/r600_pipe.h |1 +
src/gallium/drivers/r600/r600_query.c |9 +
src/gallium/winsys/radeon/drm/radeon_drm_bo.c |5 +
src/gallium/winsys/radeon/drm/radeon_drm_w
>
> This allows us to reuse this for choosing formats for MSAA limits.
Self-review, this one has a bug, I've changed in the branch
gallium-texture-multisample in my tree to take a problem boolean and
only report the problem in that case, as PIPE_FORMAT_NONE wasn't
always indicative of a problem.
Am 10.04.2013 18:50, schrieb Tom Stellard:
On Wed, Apr 10, 2013 at 05:59:48PM +0200, Michel Dänzer wrote:
[SNIP]
We should start using the updated pattern syntax for all new patterns.
This means replacing register classes with types for the input patterns
and omitting the type in the output pat
On Sat, 06 Apr 2013 08:52:35 -0600
Brian Paul wrote:
> One more comment for now below. I may not get to review the rest for
> a few days.
>
> -Brian
Thanks very much for the review. I redid properly my patch and rebase
my work on a more recent mesa version. I want to do a piglit non regressio
89 matches
Mail list logo
