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
wrote:
Trying to dig more and found out which shader is causing trouble but I
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
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
is
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
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
is
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 March 1, 2013 06:24:01 PM Matt Turner wrote:
> On Fri, Mar 1, 2013 at 5:15 PM, Sebastien Caty
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
On Fri, Mar 1, 2013 at 5:15 PM, Sebastien Caty 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 test {pass,fail,crash}
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, sen
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 improvem
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
http://lists.freedesktop.org/mailm
> >> 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 Tue, Feb 26, 2013 at 1:05 PM, Stefan Seifert 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 R600_HYPERZ=0.
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 soo
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
http://lists.freedesktop.org/mailm
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 w
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
On 02/24/2013 11:01 PM, Henri Verbeet wrote:
On 24 February 2013 17:07, Vadim Girlin 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 expla
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 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
On 02/24/2013 11:01 PM, Henri Verbeet wrote:
On 24 February 2013 17:07, Vadim Girlin 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 expla
On 24 February 2013 17:07, Vadim Girlin 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
> exact shader that ca
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
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.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.or
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 dum
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 "R600_DUMP_SH
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 "R600_DUMP_SH
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 de
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 - re
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 p
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 out
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
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 wrote:
> Stefan Seifert wrote:
>
>> Hi!
>>
>> Amazing work! I see some 50 % speed ups in FlightGear and even more. While
>> normally 3D clouds tear performance
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 the
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 th
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 imp
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 mig
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 co
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 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 concent
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 co
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 th
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 b
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 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,
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
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
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] rad
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!
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 h
On 14 February 2013 12:28, Christian König 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 think some of the bui
Am 14.02.2013 12:05, schrieb Henri Verbeet:
On 14 February 2013 11:42, 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.
I'm not sure that's really true.
On 14 February 2013 11:42, 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.
>
I'm not sure that's really true. My impression is that LLVM has a
number o
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
Greetings,
I hope that, even if you work will be short-lived, e.g. until LLVM bytecode
compiler takes off, the know-how is still very useful.
On Thu, Feb 14, 2013 at 4:04 AM, Vadim Girlin wrote:
> Hi,
>
> Last month I finally found the time to work on the rewrite of my previous
> shader optimiz
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 generated
54 matches
Mail list logo
