Sebastien Caty wrote:
On March 3, 2013 12:14:54 AM Vadim Girlin wrote:
On 03/02/2013 10:06 AM, Sebastien Caty wrote:
On March 1, 2013 06:24:01 PM Matt Turner wrote:
On Fri, Mar 1, 2013 at 5:15 PM, Sebastien Caty sc...@dcinformatique.com
wrote:
Trying to dig more and found out which shader
On 03/02/2013 10:06 AM, Sebastien Caty wrote:
On March 1, 2013 06:24:01 PM Matt Turner wrote:
On Fri, Mar 1, 2013 at 5:15 PM, Sebastien Caty sc...@dcinformatique.com
wrote:
Trying to dig more and found out which shader is causing trouble but I
haven't found out how to run a specific test with
On February 28, 2013 12:19:30 PM Vadim Girlin wrote:
Make sure that you have recent patches, some problems with R7xx chips
were fixed yesterday. Then please check if there are any regressions
with piglit tests (as compared to the piglit results with R600_SB=0). If
there are regressions, send
On Fri, Mar 1, 2013 at 5:15 PM, Sebastien Caty sc...@dcinformatique.com wrote:
Trying to dig more and found out which shader is causing trouble but I
haven't found out how to run a specific test with piglit. Documentation
isn't to friendly...Id appreciate some help with this.
If you click the
On March 1, 2013 06:24:01 PM Matt Turner wrote:
On Fri, Mar 1, 2013 at 5:15 PM, Sebastien Caty sc...@dcinformatique.com
wrote:
Trying to dig more and found out which shader is causing trouble but I
haven't found out how to run a specific test with piglit. Documentation
isn't to
On 03/02/2013 05:15 AM, Sebastien Caty wrote:
On February 28, 2013 12:19:30 PM Vadim Girlin wrote:
Make sure that you have recent patches, some problems with R7xx chips
were fixed yesterday. Then please check if there are any regressions
with piglit tests (as compared to the piglit results with
On 03/02/2013 10:06 AM, Sebastien Caty wrote:
On March 1, 2013 06:24:01 PM Matt Turner wrote:
On Fri, Mar 1, 2013 at 5:15 PM, Sebastien Caty sc...@dcinformatique.com
wrote:
Trying to dig more and found out which shader is causing trouble but I
haven't found out how to run a specific test with
All the Wine D3D tests now (3931289ab5fc7c7e2ab46e6316e55adc19ec3cfc)
pass for me on Cayman. I may be able to do some more testing later,
and do e.g. a piglit run.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
On February 28, 2013 12:19:30 PM Vadim Girlin wrote:
Do you still need some piglit test on rv790 hardware? I've also tried
running Serious Sam 3 with the standard, llvm and your optimized backend
and SS3 finally manages to not be a slideshow above the lowest settings.
Great improvement but
Could you please test glxgears and other simple mesa demos? It's easier
to spot the problems with small apps that don't use a lot of complex
shaders. If some of them don't work correctly, please send me the dumps
with R600_DUMP_SHADERS=2 R600_SB_DUMP=3.
All of the mesa demos work with
On 02/24/2013 11:01 PM, Henri Verbeet wrote:
On 24 February 2013 17:07, Vadim Girlin vadimgir...@gmail.com wrote:
If you'd like to help me with debugging the issues on cayman, then please
read the regression debugging section in the r600-sb branch notes [1] (or
possibly more up-to-date source
Great, I'll do some testing again when I get the chance.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Good news!
I gave the r600-sb branch a good testing at commit
265ae41b1f1d086d35d274c7378c43cddb8215c8 and so far I've not had a single
lockup in about 1 1/2 hours of flight time!
The downside is that this is with R600_HYPERZ=0. But with HYPERZ enabled, I
get lockups on master as well, so it
Hello,
Does your branch should works on R700 ?
I tested it on a RV770 but get many corruptions on Counter Strike Source
(native). I haven't tested anything else.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
On 02/26/2013 10:49 PM, Benjamin Bellec wrote:
Hello,
Does your branch should works on R700 ?
I tested it on a RV770 but get many corruptions on Counter Strike Source
(native). I haven't tested anything else.
There are still some known problems with r7xx chips, hopefully they'll
be fixed
On Tue, Feb 26, 2013 at 1:05 PM, Stefan Seifert n...@detonation.org wrote:
Good news!
I gave the r600-sb branch a good testing at commit
265ae41b1f1d086d35d274c7378c43cddb8215c8 and so far I've not had a single
lockup in about 1 1/2 hours of flight time!
The downside is that this is with
On 02/24/2013 11:25 PM, Vadim Girlin wrote:
On 02/24/2013 11:01 PM, Henri Verbeet wrote:
On 24 February 2013 17:07, Vadim Girlin vadimgir...@gmail.com wrote:
If you'd like to help me with debugging the issues on cayman, then
please
read the regression debugging section in the r600-sb branch
On 02/22/2013 04:35 PM, Henri Verbeet wrote:
For what it's worth, I get a number of failures in the Wine d3d9 tests
on Cayman with this branch (9219c54b5c5a65c269124637a6e654eda4cdbb8e).
I haven't looked at why yet.
Unfortunately I have no cayman card to reproduce the issues. I can only
test
On 24 February 2013 17:07, Vadim Girlin vadimgir...@gmail.com wrote:
If you'd like to help me with debugging the issues on cayman, then please
read the regression debugging section in the r600-sb branch notes [1] (or
possibly more up-to-date source here - [2]), it explains how to find the
On 02/24/2013 11:01 PM, Henri Verbeet wrote:
On 24 February 2013 17:07, Vadim Girlin vadimgir...@gmail.com wrote:
If you'd like to help me with debugging the issues on cayman, then please
read the regression debugging section in the r600-sb branch notes [1] (or
possibly more up-to-date source
Vadim Girlin wrote:
On 02/19/2013 08:39 PM, Andy Furniss wrote:
Vadim Girlin wrote:
Could you please test glxgears and other simple mesa demos? It's easier
to spot the problems with small apps that don't use a lot of complex
shaders. If some of them don't work correctly, please send me the
On 02/19/2013 08:39 PM, Andy Furniss wrote:
Vadim Girlin wrote:
Could you please test glxgears and other simple mesa demos? It's easier
to spot the problems with small apps that don't use a lot of complex
shaders. If some of them don't work correctly, please send me the dumps
with
Vadim Girlin wrote:
Testing with rv790 with drm-fixes kernel not much works -
etqw runs but in a level 50% of screen is junk.
nexuiz menus total junk, didn't test further.
xonotic menus OK but gpu lock on starting timedemo.
vdpau mpeg2 decode - renders 90% junk.
heaven 3.0 (on a different
On 02/19/2013 04:54 PM, Andy Furniss wrote:
Vadim Girlin wrote:
Testing with rv790 with drm-fixes kernel not much works -
etqw runs but in a level 50% of screen is junk.
nexuiz menus total junk, didn't test further.
xonotic menus OK but gpu lock on starting timedemo.
vdpau mpeg2 decode -
Vadim Girlin wrote:
Could you please test glxgears and other simple mesa demos? It's easier
to spot the problems with small apps that don't use a lot of complex
shaders. If some of them don't work correctly, please send me the dumps
with R600_DUMP_SHADERS=2 R600_SB_DUMP=3.
All of the mesa
On 02/19/2013 08:39 PM, Andy Furniss wrote:
Vadim Girlin wrote:
Could you please test glxgears and other simple mesa demos? It's easier
to spot the problems with small apps that don't use a lot of complex
shaders. If some of them don't work correctly, please send me the dumps
with
Stefan Seifert wrote:
Hi!
Amazing work! I see some 50 % speed ups in FlightGear and even more. While
normally 3D clouds tear performance down to an unflyable stutter, with your
branch I can fly in densly clouded conditions at usable framerates. I can now
turn all shaders to maximum and enjoy
Well, the branch was said to work with EG. For HD4000, probably further
work is needed.
On Mon, Feb 18, 2013 at 12:20 PM, Andy Furniss andy...@ukfsn.org wrote:
Stefan Seifert wrote:
Hi!
Amazing work! I see some 50 % speed ups in FlightGear and even more. While
normally 3D clouds tear
On 02/18/2013 02:20 PM, Andy Furniss wrote:
Stefan Seifert wrote:
Hi!
Amazing work! I see some 50 % speed ups in FlightGear and even more.
While
normally 3D clouds tear performance down to an unflyable stutter, with
your
branch I can fly in densly clouded conditions at usable framerates. I
can
Vadim Girlin wrote:
Unrelated question wtr heaven 3.0 - does it work properly anyway?
For me running 64bit on rv790 with vanilla mesa with or without llvm I
have to set shaders to medium, on high it works but I get no
lighting/effects. There are also a couple of scenes that render as
flared
Am 15.02.2013 22:25, schrieb Vadim Girlin:
On 02/15/2013 03:22 PM, Christian König wrote:
Am 15.02.2013 12:00, schrieb Vadim Girlin:
[SNIP]
Heaven 3.0, all settings high/enabled, 1280x720, HD5750:
default backend : 20.0 fps
llvm backend: 18.8 fps
r600-sb : 38.0 fps
Quite
On 02/16/2013 11:10 AM, Mathias � wrote:
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
On Friday 15 February 2013 02:21:56 Vadim Girlin wrote:
I pushed the fix for one problem that I noticed with FlightGear to that
branch, please test if it helps with your lockups as well.
I have a commit d6327a397ed54b3b2e40d521a762a380c25cba48 but the lockups still
occur:
[ 125.082988]
On 02/14/2013 02:42 PM, Christian König wrote:
Hi Vadim,
nice work, I think you've made quite a progress here, but on the other
hand it should be clear that the LLVM backend is the future and we
should concentrate on that.
LLVM backend is the future is a pretty abstract argument. I prefer to
Am 15.02.2013 12:00, schrieb Vadim Girlin:
On 02/14/2013 02:42 PM, Christian König wrote:
Hi Vadim,
nice work, I think you've made quite a progress here, but on the other
hand it should be clear that the LLVM backend is the future and we
should concentrate on that.
LLVM backend is the future
Just wow! It would be crime not to merge this branch, with the sole reason
LLVM is the future.
Fantastic work Vadim.
On Fri, Feb 15, 2013 at 1:00 PM, Vadim Girlin vadimgir...@gmail.com wrote:
On 02/14/2013 02:42 PM, Christian König wrote:
Hi Vadim,
nice work, I think you've made quite a
On Fre, 2013-02-15 at 15:00 +0400, Vadim Girlin wrote:
On 02/14/2013 02:42 PM, Christian König wrote:
nice work, I think you've made quite a progress here, but on the other
hand it should be clear that the LLVM backend is the future and we
should concentrate on that.
LLVM backend is
On Fri, Feb 15, 2013 at 03:00:24PM +0400, Vadim Girlin wrote:
On 02/14/2013 02:42 PM, Christian König wrote:
Hi Vadim,
nice work, I think you've made quite a progress here, but on the other
hand it should be clear that the LLVM backend is the future and we
should concentrate on that.
On 02/15/2013 03:22 PM, Christian König wrote:
Am 15.02.2013 12:00, schrieb Vadim Girlin:
On 02/14/2013 02:42 PM, Christian König wrote:
Hi Vadim,
nice work, I think you've made quite a progress here, but on the other
hand it should be clear that the LLVM backend is the future and we
should
On 02/15/2013 04:06 PM, Michel � wrote:
On Fre, 2013-02-15 at 15:00 +0400, Vadim Girlin wrote:
On 02/14/2013 02:42 PM, Christian K�nig wrote:
nice work, I think you've made quite a progress here, but on the other
hand it should be clear that the LLVM backend is the future and we
should
On 02/15/2013 06:31 PM, Tom Stellard wrote:
On Fri, Feb 15, 2013 at 03:00:24PM +0400, Vadim Girlin wrote:
On 02/14/2013 02:42 PM, Christian K�nig wrote:
Hi Vadim,
nice work, I think you've made quite a progress here, but on the other
hand it should be clear that the LLVM backend is the future
On 02/15/2013 03:22 PM, Christian König wrote:
Am 15.02.2013 12:00, schrieb Vadim Girlin:
On 02/14/2013 02:42 PM, Christian König wrote:
Hi Vadim,
nice work, I think you've made quite a progress here, but on the other
hand it should be clear that the LLVM backend is the future and we
should
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
Hi Vadim,
nice work, I think you've made quite a progress here, but on the other
hand it should be clear that the LLVM backend is the future and we
should concentrate on that.
To sum it up I'm not sure what we should do with this branch :)
As Dragomir already wrote even if the code won't be
On 14 February 2013 11:42, Christian König deathsim...@vodafone.de wrote:
nice work, I think you've made quite a progress here, but on the other hand
it should be clear that the LLVM backend is the future and we should
concentrate on that.
I'm not sure that's really true. My impression is that
Am 14.02.2013 12:05, schrieb Henri Verbeet:
On 14 February 2013 11:42, Christian König deathsim...@vodafone.de wrote:
nice work, I think you've made quite a progress here, but on the other hand
it should be clear that the LLVM backend is the future and we should
concentrate on that.
I'm not
On 14 February 2013 12:28, Christian König deathsim...@vodafone.de wrote:
Well apart from a bit strange coding style and the use of SVN, I can't
really see any problems that are related to using LLVM as it is.
Well, for one, I don't think LLVM believes in stable APIs or shared
libraries, and I
Hi!
Amazing work! I see some 50 % speed ups in FlightGear and even more. While
normally 3D clouds tear performance down to an unflyable stutter, with your
branch I can fly in densly clouded conditions at usable framerates. I can now
turn all shaders to maximum and enjoy the view. This makes a
On 02/14/2013 08:53 PM, Stefan Seifert wrote:
Hi!
Amazing work! I see some 50 % speed ups in FlightGear and even more. While
normally 3D clouds tear performance down to an unflyable stutter, with your
branch I can fly in densly clouded conditions at usable framerates. I can now
turn all shaders
On 02/14/2013 08:53 PM, Stefan Seifert wrote:
Hi!
Amazing work! I see some 50 % speed ups in FlightGear and even more. While
normally 3D clouds tear performance down to an unflyable stutter, with your
branch I can fly in densly clouded conditions at usable framerates. I can now
turn all shaders
Hi,
Last month I finally found the time to work on the rewrite of my
previous shader optimization branch, now it's mostly done in terms of
the correctness of produced code and feature support (at least on
evergreen), though it's still a work in progress in terms of the
efficiency of
51 matches
Mail list logo
