Hi,
On Thursday, October 27, 2011 18:17:41 Marek Olšák wrote:
Looks good to me. Ideally even texture_barrier should not be needed.
set_framebuffer_state() and flush() should flush caches automatically.
If they don't, there is a bug.
I have pushed this now as an improovement above the former
Michael,
On Thursday, November 10, 2011 18:42:13 Michel Dänzer wrote:
On Don, 2011-11-10 at 11:01 +0100, Theiss, Ingo wrote:
The function calls of mesa/state_tracker/st_cb_readpixels.c:382 -
st_readpixels and mesa/main/pack.c:552 - _mesa_pack_rgba_span_float
clearly stands out when
Introduce a set of defines for VERT_ATTRIB_* and VERT_BIT_*
that will be used in the followup patches.
---
src/mesa/main/context.c | 29 ++
src/mesa/main/mtypes.h | 60 --
2 files changed, 71 insertions(+), 18 deletions(-)
---
src/mesa/vbo/vbo_context.c| 26 +++---
src/mesa/vbo/vbo_exec.h |4 ++--
src/mesa/vbo/vbo_exec_api.c | 24
src/mesa/vbo/vbo_exec_array.c | 41
+
src/mesa/vbo/vbo_exec_draw.c | 22
Consolidate the two distinct set of flags to use VERT_BIT_*.
---
src/mesa/main/arrayobj.c |2 +-
src/mesa/main/enable.c | 20 ++--
src/mesa/main/mtypes.h | 37 ++---
src/mesa/main/varray.c | 36 ++--
---
src/mesa/main/context.c |2 +-
src/mesa/main/enable.c |2 +-
src/mesa/main/mtypes.h | 54 +++---
src/mesa/main/varray.c |2 +-
4 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/src/mesa/main/context.c
---
src/mesa/main/context.c|2 +-
src/mesa/main/ff_fragment_shader.cpp |2 +-
src/mesa/main/ffvertex_prog.c | 18 +-
src/mesa/main/mtypes.h |4 ++--
src/mesa/main/state.c
Hi all,
following a patch series to make gl_array_object use a VERT_ATTRIB_*
indexed array of gl_client_array structs.
Since we have already 33 client arrays in an array object the VERT_BIT_* and
for vertex shader inputs bitmaps are extended to 64 bits. Drivers
and shader code is updated to use
---
src/mesa/drivers/dri/r200/r200_vertprog.c | 31 ++--
1 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/dri/r200/r200_vertprog.c
b/src/mesa/drivers/dri/r200/r200_vertprog.c
index 697073e..bf87d80 100644
---
---
src/mesa/drivers/dri/i915/i915_fragprog.c |4 ++--
src/mesa/drivers/dri/i965/brw_context.h |2 +-
src/mesa/drivers/dri/i965/brw_draw_upload.c |6 +++---
src/mesa/drivers/dri/i965/brw_vs.c |4 ++--
src/mesa/drivers/dri/i965/brw_vs_constval.c |2 +-
The NV_vertex_program generic attributes should alias the legacy
attributes. Simplify aliasing by using the same gl_client_arrays
for legacy and NV_vertex_program attributes.
The same is already done for the current state values.
---
src/mesa/main/enable.c| 10 ++--
src/mesa/main/get.c
Now the gl_array_object's layout matches the one used in
recalculate_input_bindings. Make use of this and remove the
bind_array_obj function.
---
src/mesa/vbo/vbo_exec.h |6
src/mesa/vbo/vbo_exec_array.c | 53 +++-
2 files changed, 15
Hi,
On Thursday, November 17, 2011 00:47:22 Brian Paul wrote:
I did a quick read of these patches and they look pretty good. I'd
like to go over them again though. Another set of eyes would be good
too. I'll try to finish reviewing by the end of the week.
Thanks, I have a busy week too,
.
The patchset survives a r600 piglit run on my favourite rv670 development
machine with no regressions.
Please review.
Thanks
Mathias
Mathias Fröhlich (6):
mesa: Introduce more symbolic VERT_{ATTRIB,BIT}* defines.
mesa: Replace _NEW_ARRAY_* bits with VERT_BIT_*
vbo: Use The VERT_{ATTRIB
Introduce a set of defines for VERT_ATTRIB_* and VERT_BIT_*
that will be used in the followup patches.
Signed-off-by: Mathias Froehlich mathias.froehl...@web.de
---
src/mesa/main/mtypes.h | 63 ++-
1 files changed, 45 insertions(+), 18 deletions(-)
Consolidate the two distinct set of flags to use VERT_BIT_*.
Signed-off-by: Mathias Froehlich mathias.froehl...@web.de
Reviewed-by: Brian Paul bri...@vmware.com
---
src/mesa/main/arrayobj.c |2 +-
src/mesa/main/enable.c | 20 ++--
src/mesa/main/mtypes.h | 37
Signed-off-by: Mathias Froehlich mathias.froehl...@web.de
Reviewed-by: Brian Paul bri...@vmware.com
---
src/mesa/vbo/vbo_context.c| 26 +++---
src/mesa/vbo/vbo_exec.h |4 ++--
src/mesa/vbo/vbo_exec_api.c | 24
Signed-off-by: Mathias Froehlich mathias.froehl...@web.de
Reviewed-by: Brian Paul bri...@vmware.com
---
src/mesa/main/enable.c |2 +-
src/mesa/main/mtypes.h | 54
src/mesa/main/varray.c |2 +-
3 files changed, 29 insertions(+), 29
Make gl_program::InputsRead a 64 bits bitfield.
Adapt the intel and radeon driver to handle a 64 bits
InputsRead value.
Signed-off-by: Mathias Froehlich mathias.froehl...@web.de
---
src/mesa/drivers/dri/i915/i915_fragprog.c |4 +-
src/mesa/drivers/dri/i965/brw_context.h|2 +-
Hi,
On Sunday, November 27, 2011 22:52:29 Eric Anholt wrote:
Not an issue for this patch, but I noticed that there's this
_mesa_update_array_object_max_element that does something similar, but
doesn't follow this rule and would trash the _MaxElement value. Some
day, the body of this
Hi,
Apologies for braking this!
Thanks, looks great.
Mathias
On Tuesday, November 29, 2011 08:22:58 Chia-I Wu wrote:
From: Chia-I Wu o...@lunarg.com
Fix build errors since 762c9766c93697af8d7fbaa729aed118789dbe8e.
---
src/mesa/main/ffvertex_prog.c |2 +-
src/mesa/main/get.c
Hi,
On Wednesday, November 30, 2011 07:58:08 Jose Fonseca wrote:
It looks like there is a regression,
https://bugs.freedesktop.org/show_bug.cgi?id=43353 . Can you investigate
this?
Sure
Mathias
___
mesa-dev mailing list
These two patches should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=3D43353
Please review.
Mathias Fröhlich (2):
mesa: Extend BITSET64_*_RANGE to work on arbitrary ranges.
mesa: Renumber the tnl attributes to match VERT_ATTRIB*.
src/mesa/main/bitset.h | 21
The BITSET64_{TEST,SET,CLEAR}_RANGE macros only work on ranges
wither in the lower 32 or in the upper 32 bits of the bitset.
This change extends these macros to work on arbitrary ranges
possibly crossing the bitset word boundary.
Signed-off-by: Mathias Froehlich mathias.froehl...@web.de
---
Also renumber the tnl modules vertex attributes to match
the renumbered VERT_ATTRIB_* values.
This should fix
https://bugs.freedesktop.org/show_bug.cgi?id=43353
Signed-off-by: Mathias Froehlich mathias.froehl...@web.de
---
src/mesa/tnl/t_context.h | 58
Hi,
The attached patch fixes a core dump in glReadPixels with traditional swrast.
The problem looks pretty much the same like the one the VTK guy Kevin H. Hobbs
reports. At least his backtrace is mostly the same.
Please review.
Thanks
Mathias
From 92eaecb0f471d6705121ca346b43e3709989847f Mon
Hi,
Attached is a change to the ARB program parser that should fix
https://bugs.freedesktop.org/show_bug.cgi?id=43407
Please review.
Thanks
Mathias
From 4a3d9f06651c5cd51edcb394fa598153e5fea2f3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mathias=20Fr=C3=B6hlich?= mathias.froehl...@web.de
Date:
Hi,
On Thursday, December 01, 2011 17:53:45 Simon Farnsworth wrote:
It's unclear exactly what the alignment requirements are for Radeon tiled
surfaces, but they differ between the DDX and Mesa. Make Mesa match the
DDX.
Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
Brian,
On Thursday, December 15, 2011 17:08:57 Brian Paul wrote:
There's a regression in vertex array drawing with this commit:
commit ed42c2580717527b2005580940fc766d95bb6b0b
Author: Mathias Fröhlich mathias.froehl...@web.de
Date: Mon Oct 31 16:23:40 2011 +0100
vbo: Use
Brian,
On Thursday, December 15, 2011 22:36:24 you wrote:
I found the problem. It's this chunk in vbo_context.c:
[...]
For fixed function, the point is to simply place the per-vertex
material attributes in the generic attribute arrays. There are 12
such material attributes. So there's
Hi,
attached is a change that fixes a problem with the isosurf mesa demo.
Please review.
Mathias
From ce63927e24df800ab6c89554ae9b2096cd79122a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mathias=20Fr=C3=B6hlich?= mathias.froehl...@web.de
Date: Fri, 16 Dec 2011 20:16:52 +0100
Subject: [PATCH]
Brian,
On Monday, December 19, 2011 17:01:07 you wrote:
I still don't get what the purpose of the special mapping of the last
four/five elements is all about. Can you explain that?
As far as I can see the last ones should not map to anything.
The map is used only in fixed function mode. And
Marek,
On Tuesday, December 20, 2011 01:40:46 Marek Olšák wrote:
The problem back in March and earlier was that the vertex array state
was completely recomputed for each draw call even if the user did not
change any state at all! There was the validation in the vbo module
and then in
Hi,
On Thursday, December 22, 2011 18:30:44 Brian Paul wrote:
I'm not sure if playback_vertex_list is more like DRAW_BEGIN_END or
DRAW_ARRAYS.
Maybe add a DRAW_DISPLAY_LIST enum value?
It's more like begin/end I think.
The begin/end code just sets the array state below the state tracking of
Hi Brian,
On Saturday, December 24, 2011 16:38:09 Brian Paul wrote:
From: Brian Paul bri...@vmware.com
This fixes a regression seen with the isosurf demo when switching between
glBegin/End and glDrawArrays (do it several times). The problem was the
driver wasn't getting _NEW_ARRAY when
Hi,
I have posted a very similar patch already with the array object change
series. But I have omitted applying this one because of a general issue that
Brian pointed me to in a patch prior to this one in the series.
But it turns out that this one should be still safe.
Please review
Thanks
Hi,
On Sunday, December 25, 2011 10:03:34 Marek Olšák wrote:
I did not fix Torcs. I think optimizing apps is useless if the same
optimization can be done in Mesa too.
Ok, so any torcs version should show a performance difference to check against.
Do you have any test program that could be
reviews and tests are
very welcome.
Please review.
Thanks
Mathias
Mathias Fröhlich (5):
mesa: Convert RENDERINPUTS* macros to GLbitfield64.
i915: Convert to use GLbitfield64 directly.
nouveau: Convert to use GLbitfield64 directly.
radeon: Convert to use GLbitfield64 directly.
mesa
Signed-off-by: Mathias Froehlich mathias.froehl...@web.de
---
src/mesa/drivers/dri/i915/i830_context.h |2 +-
src/mesa/drivers/dri/i915/i830_vtbl.c| 24 +++-
2 files changed, 12 insertions(+), 14 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i830_context.h
Signed-off-by: Mathias Froehlich mathias.froehl...@web.de
---
src/mesa/main/mtypes.h |6 ++
src/mesa/tnl/t_context.h | 25 +
2 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 02452aa..28cf6d7
Signed-off-by: Mathias Froehlich mathias.froehl...@web.de
---
src/mesa/drivers/dri/nouveau/nouveau_swtnl_t.c |2 +-
src/mesa/drivers/dri/nouveau/nv04_render.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_swtnl_t.c
Signed-off-by: Mathias Froehlich mathias.froehl...@web.de
---
src/mesa/swrast_setup/ss_context.c | 30 +-
src/mesa/swrast_setup/ss_context.h |2 +-
src/mesa/tnl/t_context.c | 20 +---
src/mesa/tnl/t_context.h | 14
Hi,
On Tuesday, December 27, 2011 00:17:09 Brian Paul wrote:
LGTM. I presume you've done a piglit run and tested with a few other
things?
I have run piglit quick with classic swrast an piglit r600g on gallium rv670
with this change. Also I am pretty sure that I have started osgviewer and
Hi,
On Tuesday, December 27, 2011 00:37:13 Brian Paul wrote:
For the series:
Reviewed-by: Brian Paul bri...@vmare.com
Thanks.
What is your preference to do with the remaining bitset.h header?
* Remove this as ununsed?
* Remove the 64 bit bitset implementation as this could be better done with
Hi,
On Wednesday, December 28, 2011 03:22:31 Jose Fonseca wrote:
It looks like bitset.h is still used by classic nouveau driver -- see `git
grep '\BITSET_'`-- and the state stored in it is too big to fit in 64bit
integers (it requires approximately 87 bits). There doesn't seem to be an
Hi,
On Thursday, December 29, 2011 13:35:19 Michel Dänzer wrote:
From: Michel Dänzer michel.daen...@amd.com
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=44151
Probably fixes: https://bugs.freedesktop.org/show_bug.cgi?id=44007
: Add pipe_mutex_destroy() call for newly added mutex.
Reviewed-by: Mathias Fröhlich mathias.froehl...@web.de
Greetings
Mathias
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Signed-off-by: Mathias Fröhlich mathias.froehl...@web.de
---
src/mesa/main/mtypes.h | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 107371e..451d442 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main
Use a bitmask approach to compute gl_array_object::_MaxElement.
To make this work reliably depending on the shader type actually used,
make use of the newly introduced typed bitmaks getters.
With this change I gain about 5% draw time on some osgviewer examples.
Signed-off-by: Mathias Fröhlich
Hi Eric,
Thanks for the review.
I will send shortly an updated patch.
... except:
On Friday, December 30, 2011 12:13:36 Eric Anholt wrote:
Also, I think that helper would be easier to read as;
+ GLbitfield64 enabled = arrayObj-_Enabled;
+
+ if (enabled VERT_ATTRIB_GENERIC0)
+
Hi,
Thanks for the first review.
Following a short followup series to the gl_array_object change.
The most important change is the use ot an ffs based loop to compute
gl_array_object::_MaxElement. This change provides a noticable performance
improovement for my average workloads.
To implement
Signed-off-by: Mathias Fröhlich mathias.froehl...@web.de
---
src/mesa/main/mtypes.h | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 9fdabf9..b381ad2 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main
Hi,
We have experienced a problem with the win32 wgl pbuffer implementation using
gallium together with threading.
This attached change releases the stw_framebuffer::mutex past creation of
the pbuffer stw_framebuffer. Without this change the pbuffers
lock is never released. Since on win32
Hi,
The attached change just makes the bitfield macro match the register number it
is used for. Both actually expand into the same values.
Please apply
Thanks!
Mathias
From eaf61856ba5e40700a4b562fc38750f66cf7cba1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mathias=20Fr=C3=B6hlich?=
Hi,
This patch restores the previous memory characteristic of the recently removed
r600g winsys. Static and immutable buffers were placed in any case in vram.
This really improoves rendering performance for some OpenSceneGraph based
applications I often use for testing here.
Please review and
Hi Jose,
On Thursday, October 13, 2011 20:18:25 Jose Fonseca wrote:
We should also acquire/release the mutex on every entry point on that file
for consistency, but it would make no difference, given that pbuffers
can't be resized like normal windows are.
Do you have commit access or should
Hi,
On Thursday, October 13, 2011 21:35:05 Alex Deucher wrote:
Follow the instructions here:
http://www.freedesktop.org/wiki/AccountRequests
Will do, thanks!
Mathias
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
the buffer objects mutex while modifying reference
counts for push/pop of client array attributes.
Also ensure that each taken reference on push is released
on pop.
Signed-off-by: Mathias Fröhlich mathias.froehl...@web.de
---
src/mesa/main/attrib.c | 108
Hi Brian,
On Tuesday, October 18, 2011 17:05:53 Brian Paul wrote:
This was brought up a few weeks ago by someone else. I had posted the
start of a patch to fix it. I'm attaching an updated version that I
think is pretty clean. But there's a few lines missing and it's
totally untested.
Hi,
On Wednesday, October 19, 2011 16:32:57 Brian Paul wrote:
As a first cut, I want something that works correctly and is easy to
understand and maintain. We can optimize later if needed. I think
most seasoned OpenGL programmers know that glPush/PopAttrib isn't
exactly a high-performance
name
that was just deleted and never rebound in between.
The explicit rebinding to the debault object in the current context
prevents the above in the current context, but an other context
sharing the same objects might suffer from this problem.
Signed-off-by: Mathias Fröhlich mathias.froehl
the array attrib push/pop implementation
to be thread safe. Make use of more library functions
for this purpose.
Signed-off-by: Mathias Fröhlich mathias.froehl...@web.de
---
src/mesa/main/attrib.c | 223
1 files changed, 151 insertions(+), 72
Hi,
The attached patch reduces the amount of pipe flushes for r600g.
I am not exactly sure if we could skip this flush entirely because of the
internal r600g winsys flush logic.
But what we can do is the attached patch:
Replace pipe-flush() with pipe-texture_barrier() in
the texture upload
Hi,
the attached patch enables opengl client side throtteling for r600g that
recently slipped in as an infrastructure but is just enabled for vmgfx so far.
The benefits of the client side throtteling are great, since a single render
intensive application is no longer able to just saturate the
Hi,
On Sunday, October 23, 2011 17:53:53 Brian Paul wrote:
Looks good. Just minor things:
In other places where we have a field like this it's called DeletePending.
The comment you added in _mesa_DeleteBuffersARB() is a bit hard to
understand. If you need help, I could rewrite it for
Hi,
On Sunday, October 23, 2011 17:55:52 Brian Paul wrote:
Reviewed-by: Brian Paul bri...@vmware.com
I think it would be really good to have even a simple, single-threaded
piglit test for this (glPush, glDeleteBufferObj, glPop). Could you
write one?
Pushing this on top of the todo list
On Saturday, January 26, 2013 08:42:41 bugzilla-dae...@freedesktop.org wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=59877
Tom Stellard tstel...@gmail.com changed:
What|Removed |Added
Hi,
On Friday, February 15, 2013 15:00:24 Vadim Girlin wrote:
LLVM backend is the future is a pretty abstract argument. I prefer to
operate with real facts. After a year of LLVM backend development what
are the real benefits for the users? What are the real use cases where
the users might
Tom,
-class LLVMEnsureMultithreaded {
-public:
- LLVMEnsureMultithreaded()
- {
- llvm_start_multithreaded();
- }
-};
-
-static LLVMEnsureMultithreaded lLVMEnsureMultithreaded;
Removing this leads to crashes in llvm with applications that concurrently
work on different gl
it works stable if we ensure llvm being multithreaded.
So, I tried to distill a piglit testcase out of this somehow huger setup with
flightgear, OpenSceneGraph, multiple gpu's and what not.
On Friday, April 19, 2013 20:08:54 Tom Stellard wrote:
On Wed, Apr 17, 2013 at 07:54:32AM +0200, Mathias
Hi all,
On Monday, April 22, 2013 00:39:57 Tom Stellard wrote:
[...]
The only pro for further investigating the dlopen flags is that I fear the
distribution builders who invented dynamic linking in the drivers. That change
destroyed symbol isolation in the drivers at that point. They will
/tests/general/driver-isolation-library.c
@@ -0,0 +1,36 @@
+/*
+ * Copyright (c) 2013 Mathias Fröhlich.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without
Hi,
On Wednesday, April 24, 2013 14:15:06 Tom Stellard wrote:
I've thought about this some more, and I think that the best solution
might be to move all LLVM API calls into gallivm and build it as a
shared object with it's own private copy of LLVM statically linked. This
way we would still
Hi,
On Wednesday, April 24, 2013 21:54:02 Jose Fonseca wrote:
I don't see how this would work -- llvmpipe/draw has LLVMBuildXxxx calls
too. So to prevent symbol collision with apps that use them, we'd need to
expose all LLVM calls we need under nome unique prefix.
Also note that gallivm
Jose,
On Thursday, April 25, 2013 01:38:46 Jose Fonseca wrote:
What I'm suggesting doesn't require huge effort.
In detail, I'm suggesting:
(1) have a custom build of LLVM libraries with -fvisibility=hidden
(2) have a src/mesallvm/mesallvm.c containing wrappers
#include
Jose,
On Thursday, April 25, 2013 03:52:44 Jose Fonseca wrote:
There is no paradox. To be clear:
Ok, thanks!
Mathias
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hi,
On Thursday, April 25, 2013 10:29:27 Jose Fonseca wrote:
- There are a bunch of options that need to be set via globals, (see
lp_set_target_options), so app/drivers could tamper with each other
options.
- llvm::cl::ParseCommandLineOptions will complain if called multiple times
-- I
Tom, Jose,
On Tuesday, April 30, 2013 16:56:56 Tom Stellard wrote:
I took the linker script from your email and took at shot at creating
libMesaLLVM.so within Mesa. I've pushed my initial code here:
http://cgit.freedesktop.org/~tstellar/mesa/log/?h=libmesallvm
Thank you very much and sorry
Hi,
Sorry for these late response. I am in the middle of moving to a new
appartements coordinating work in the new one and so on.
It might even be that I do have no good network access for a few days ...
On Wednesday, May 01, 2013 17:56:33 Tom Stellard wrote:
Thanks for pointing this out,
Tom,
The series
Reviewed-by: mathias.froehl...@web.de
Greetings
Mathias
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hi,
On Monday, November 05, 2012 20:38:24 Tom Stellard wrote:
I think you will have better luck narrowing down the issue if you bisect
Mesa, rather than LLVM.
I see something that looks for the first cut at least quiet similar.
Reverting
commit 84b437213294ff4e1a3bcae2f9cbb36a9b4955c4
Hi Vincent,
On Tuesday, November 06, 2012 12:14:52 Vincent Lejeune wrote:
Do you use the master branch ?
Yes, e3213f01f7764af573ed641a7bc98dde5824e321 is my current head in llvm.
This commit generates some llvm.R600.store.pixel.color/stencil/depth
intrinsics, which were introduced by this
Vincent,
On Wednesday, November 07, 2012 08:32:03 Vincent Lejeune wrote:
git seems to have trouble sending my patch to ML atm, can you manually apply
it ? It fixes lock up here
diff --git a/src/gallium/drivers/r600/r600_asm.c
b/src/gallium/drivers/r600/r600_asm.c index 5f2548e..f06af44
Marek,
Regarding swap handling, there was a lengthy discussion about this topic at
XDC in Nürnberg.
May be Keith can comment on that as he also presented these ideas.
But short, the overall aim of this discusstion was to make the dri2 buffer swap
more asynchronous.
This does not exactly solve
Hi,
On Thursday, November 15, 2012 19:04:51 Marek Olšák wrote:
Yes, that's what I am looking for, though I'd like to have a solution
that works with current DRI2 as well.
The triple flush is unrelated to DRI2, it's actually an internal issue
with libGL and can be fixed easily.
So may be
Jose,
On Saturday, January 12, 2013 17:22:03 Jose Fonseca wrote:
That work has been merged (w/ LLVM 3.1 and MC-JIT support), however it's
quite likely that's there are still race conditions, as nobody has been
pursuing llvmpipe thread-safety so far.
Given the findings that lead to commit
Hi,
On Monday 17 May 2010 20:51:09 Corbin Simpson wrote:
I'm going to be proactive here, and pull in both this patch and a docs
update.
Great!
Thanks!
anyway a small followup on the time units is attached.
Please apply.
Mathias
diff --git a/src/gallium/docs/source/context.rst
)
add_executable (vbo-map-remap vbo-map-remap.c)
/*
* Copyright © 2009 Intel Corporation
* Copyright © 2010 Mathias Fröhlich
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the Software),
* to deal
Hi,
On Tuesday 18 May 2010 21:09:56 Will Dyson wrote:
Wire up _mesa_meta_GenerateMipmap() for radeon. This greatly improves the
playability of some games, such as FlightGear and the recently GPL'd game
Lugaru.
Great thanks!
So, turning the view most probably no longer hangs due to generating
Hi,
On Monday 17 May 2010 20:51:09 Corbin Simpson wrote:
I'm going to be proactive here, and pull in both this patch and a docs
update.
Ok.
Now that the infrastructure is there.
My initial aim was to have something to profile the r300g driver.
It already runs nicer then the classic one for
Hi,
On Monday 24 May 2010 23:08:41 Brian Paul wrote:
I hacked on the code a bit:
1. remove dead/unused code
2. Test the 64-bit query functions
3. fix the GL_QUERY_COUNTER_BITS check
4. fix indentation
Updated version attached. I'll commit in a day or so if there's no
feedback.
Looks
Hi,
On Sunday 23 May 2010 18:15:09 you wrote:
You might try latest xf86-video-ati from git, there's ColorTiling enabled
by default, which should give you nice performance increase in all 3D
apps. As for timer queries, I think there's quite a bit of work to do in
the kernel too. However, we
Hi,
The attached patch against r300g moves the cast to an unsigned past the
compare and clamp against 0.
Without the patch negative values are wrapped to huge numbers instead of
clamped to zero.
Please apply.
Mathias
diff --git a/src/gallium/drivers/r300/r300_state.c
Hi,
On Tuesday, November 16, 2010 20:21:26 Jerome Glisse wrote:
So i looked a bit more at what path we should try to optimize in the
mesa/gallium/pipe infrastructure. Here are some number gathers from
games :
drawcall / ps constant vs constant ps samplervs sampler
doom3
Hi,
Attached is a patch to r300g that avoids returning a 4 element vector in a
static array. The patch should fix a potential race with multiple contexts in
multiple threads.
Please review/apply.
Thanks!
Mathias
diff --git a/src/gallium/drivers/r300/r300_emit.c
Hi,
I am not exactly sure about this one.
But at least the the OpenGL state stracker misses the translation of the
GL_MAP_INVALIDATE_*_BITs.
I would guess that the attached patch is an appropriate tranlsation of these
into the PIPE_TRANSFER_DISCARD flag.
Please review/apply.
Thanks!
Mathias
Hi,
On Friday, November 26, 2010 22:06:47 Brian Paul wrote:
We don't have a gallium flag that directly corresponds to
GL_MAP_INVALIDATE_BUFFER_BIT but using PIPE_TRANSFER_DISCARD is
acceptable. I'll commit the patch. Thanks!
That's what it looked to me too.
Thanks!
Mathias
Hi,
Attached it a patch that omits the copy to current in display lists that are
built from draw calls that allow the current state to be undefined like
glDrawArrays, ...
That change moves the copy to current function down in profiles.
Also ctx-NewState is set less often which might save some
Hi,
On Thursday, December 09, 2010 22:36:35 Jerome Glisse wrote:
Haven't looked closely at the change but do you know a mesa demos that
shows the performance improvement ?
I have not looked for something inside mesa.
The patch is driven from a reduction in draw times from 1.45ms to 1.35ms
Hi,
On Tuesday, January 04, 2011 02:27:41 Ian Romanick wrote:
7.10 list:
commit b3d2ec9942303d1d03e28a25b030eb060415abfb
Author: Mathias Fröhlich mathias.froehl...@web.de
Date: Sun Oct 17 18:16:30 2010 +0200
vbo: Avoid the copy to current in dlists if not required
1 - 100 of 416 matches
Mail list logo
