Hi Tom,
I'm not too qualified to review the llvm code changes, but the changes
looked sane. I did want to point out a few piglit changes/regressions as a
result of this set of patches.
For my HD6850, running latest llvm from git:
gegl-rgb-gamma-u8-to-ragabaf: pass -> fail
v3i32-stack: pass -> fai
Hi,
The attached patchset implements a few optimizations for the bfgminer
bitcoin mining program.
Please Review.
-Tom
>From 661e832408a8bafc03a7c4c600c4a140b03054b4 Mon Sep 17 00:00:00 2001
From: Dmitry Cherkassov
Date: Thu, 7 Mar 2013 20:17:59 +0400
Subject: [PATCH 1/3] R600: Add 64-bit load/s
Hi,
I've generated a patch from the master branch of my llvm tree
(http://cgit.freedesktop.org/~tstellar/llvm/) that can be applied against
the LLVM 3.2 code base to add the R600 backend.
For the Mesa 9.1 release, this patch is required in order to use the
radeonsi driver, experimental compute su
Hi,
On Wednesday, I will be stabilizing my LLVM tree in preparation for the
Mesa 9.1 release. From that point on, I will only accept bug fixes for
that tree. New feature development should be based off of the upstream LLVM
SVN tree (If you don't like SVN you can use git svn, it works well for
me
Hi Tom,
the following patches should fix the known issues with the structurizer and
also optimize it a bit more.
The first two are already tested by Michel. I tested the last one with radeonsi
and it doesn't seem to regress anything and actually fixes four more piglit
tests.
Please apply to y
On 10/31/2012 07:41 AM, Jerome Glisse wrote:
For it to look right we need mesa to call into the kernel to tell the
kernel what is the bo tiling format. We should do that for scanout
buffer. This will fix your issue and you probably want 2d tiled not 1d
for scanout.
Anyway, since I do need this,
On Tue, Oct 30, 2012 at 8:49 PM, Tzvetan Mikov wrote:
> On 10/30/2012 05:20 PM, Tzvetan Mikov wrote:
>>
>> Thanks a lot! I reproduced the same results here and I think I have
>> figured out what the problem is. The frame buffer is always created in
>> linear mode. The temporary hack included below
On 10/30/2012 05:20 PM, Tzvetan Mikov wrote:
Thanks a lot! I reproduced the same results here and I think I have
figured out what the problem is. The frame buffer is always created in
linear mode. The temporary hack included below doubles the performance
for me with EGL.
Could you please check i
On Wed, Oct 31, 2012 at 1:20 AM, Tzvetan Mikov wrote:
> On 10/30/2012 11:45 AM, Jerome Glisse wrote:
>>
>> So tested, it's something inside egl that lead to this, same program
>> as yours with glut on X11 with 2d tiling enabled and 2d color tiling
>> have a slight advantage 140fps vs 137fps (windo
On 10/30/2012 11:45 AM, Jerome Glisse wrote:
So tested, it's something inside egl that lead to this, same program
as yours with glut on X11 with 2d tiling enabled and 2d color tiling
have a slight advantage 140fps vs 137fps (windowed so there is a blit
which would account for a hugue chunk of per
On Tue, Oct 30, 2012 at 10:43 AM, Tzvetan Mikov wrote:
> On 10/30/2012 07:12 AM, Patrick Baggett wrote:
>> Is your screen refresh rate 70 Hz? Because if so, that means that it's
>> syncing to the vblank on Mesa, and not doing so on the proprietary one.
>
> Unfortunately no. In fact the Gallium EGL
On 10/30/2012 07:12 AM, Patrick Baggett wrote:
> Is your screen refresh rate 70 Hz? Because if so, that means that it's
> syncing to the vblank on Mesa, and not doing so on the proprietary one.
Unfortunately no. In fact the Gallium EGL/R600 doesn't support flip on
vsync at all - eglSwapInterval is
Is your screen refresh rate 70 Hz? Because if so, that means that it's
syncing to the vblank on Mesa, and not doing so on the proprietary one.
Patrick
On Mon, Oct 29, 2012 at 8:24 PM, Tzvetan Mikov wrote:
> On 10/28/2012 12:56 PM, Tzvetan Mikov wrote:
>
>> On 10/28/2012 04:26 AM, Marek Olšák wr
On 10/28/2012 12:56 PM, Tzvetan Mikov wrote:
On 10/28/2012 04:26 AM, Marek Olšák wrote:
No, there is no X11 at all. I am running my tests on a very bare system
with EGL only, hoping to minimize the test surface and isolate any
interferences.
I will try it though (it will also enable me to compar
On 10/28/2012 04:26 AM, Marek Olšák wrote:
> Did you also turn on ColorTiling2D through xorg.conf? If not, you
> might try that and see what happens.
No, there is no X11 at all. I am running my tests on a very bare system
with EGL only, hoping to minimize the test surface and isolate any
interfere
On 10/27/2012 07:37 PM, Matt Turner wrote:
>> for ( float angle = 0; ; angle += 0.5 )
>> {
>> if (angle >= 360)
>> angle -= 360;
>>
>> display( angle );
>> glFlush();
>> eglSwapBuffers( dpy, screenSurf );
>
> Do you actually need glFlush()?
>
> It might be a case of
> ht
Did you also turn on ColorTiling2D through xorg.conf? If not, you
might try that and see what happens.
Marek
On Sun, Oct 28, 2012 at 1:53 AM, Tzvetan Mikov wrote:
> On 10/27/2012 06:58 AM, Marek Olšák wrote:
>> If you upload the texture every frame, set pipe_resource::usage to
>> PIPE_USAGE_STAG
On Sat, Oct 27, 2012 at 4:51 PM, Tzvetan Mikov wrote:
> On 10/26/2012 08:45 PM, Jerome Glisse wrote:
>>> This is interesting. All I am doing is rotating a big texture on the
>>> screen. I am using EGL+Gallium, so it is as simple as it gets.
>>>
>>> The hack I am using to disable texture tiling is
On 10/27/2012 06:58 AM, Marek Olšák wrote:
> If you upload the texture every frame, set pipe_resource::usage to
> PIPE_USAGE_STAGING. That will make the texture linear.
>
> Marek
No, I am not uploading it for every frame. It is a static texture. I am
getting only 35 FPS on a HD6460, which is path
On 10/26/2012 08:45 PM, Jerome Glisse wrote:
>> This is interesting. All I am doing is rotating a big texture on the
>> screen. I am using EGL+Gallium, so it is as simple as it gets.
>>
>> The hack I am using to disable texture tiling is also extremely simple
>> (see below). It speeds up the FPS me
If you upload the texture every frame, set pipe_resource::usage to
PIPE_USAGE_STAGING. That will make the texture linear.
Marek
On Sat, Oct 27, 2012 at 4:26 AM, Tzvetan Mikov wrote:
>> -Original Message-
>> From: Jerome Glisse
>
>> > Can anyone shed some light on this? Is this by design
On Fri, Oct 26, 2012 at 10:26 PM, Tzvetan Mikov wrote:
>> -Original Message-
>> From: Jerome Glisse
>
>> > Can anyone shed some light on this? Is this by design - e.g. is
>> > this a case of "we know that tiling is currently slower than linear
>> > but the huge payoff is scheduled to arriv
> -Original Message-
> From: Jerome Glisse
> > Can anyone shed some light on this? Is this by design - e.g. is
> > this a case of "we know that tiling is currently slower than linear
> > but the huge payoff is scheduled to arrive in a future revision"?
> >
> > Thanks!
> > Tzvetan
>
> No,
On Fri, Oct 26, 2012 at 8:07 PM, Tzvetan Mikov wrote:
> Hi,
> I have been running tests with Mesa 9.0 and Rdeon R600 (Radeon HD 6460) and I
> accidentally noticed that a small hack I did to disable texture tiling,
> actually *doubles* the frame rate. With different chips (e.g. 6750) the
> diffe
Hi,
I have been running tests with Mesa 9.0 and Rdeon R600 (Radeon HD 6460) and I
accidentally noticed that a small hack I did to disable texture tiling,
actually *doubles* the frame rate. With different chips (e.g. 6750) the
difference is less pronounced, but in all cases texture tiling decreas
Hi,
The change looks good. I have commited it to Mesa.
Marek
On Fri, Aug 31, 2012 at 6:57 PM, Vic Lee wrote:
> Hi,
>
> In my application, I need to read pixels back to system memory for every
> rendered frame. My approach is to create a chain of textures with
> PIPE_USAGE_STAGING flag, and copy
Hi,
In my application, I need to read pixels back to system memory for every
rendered frame. My approach is to create a chain of textures with
PIPE_USAGE_STAGING flag, and copy the render target to the staging
textures before reading them to avoid pipeline stall.
Now I found out as in the pa
Marek Olšák wrote:
I have fixed this master. You were right - tiling on 422 was broken.
Ok, thanks, working now.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
I have fixed this master. You were right - tiling on 422 was broken.
Marek
On Wed, Aug 8, 2012 at 1:04 AM, Andy Furniss wrote:
> Marek Olšák wrote:
>>
>> Do you have any idea what could be wrong with the patch? Also could
>> please tell me how to setup VDPAU and where to download the tests, so
>
Marek Olšák wrote:
Do you have any idea what could be wrong with the patch? Also could
please tell me how to setup VDPAU and where to download the tests, so
that I can test this.
I don't know about the patch.
One thing which may be a clue or a red herring is that when Christian
first implemen
On Tue, Aug 7, 2012 at 5:43 PM, Marek Olšák wrote:
> Do you have any idea what could be wrong with the patch? Also could
> please tell me how to setup VDPAU and where to download the tests, so
> that I can test this.
Just add:
--enable-vdpau
to your mesa configure line to enable it. To test it,
Do you have any idea what could be wrong with the patch? Also could
please tell me how to setup VDPAU and where to download the tests, so
that I can test this.
Marek
On Tue, Aug 7, 2012 at 11:25 AM, Andy Furniss wrote:
> Marek Olšák wrote:
>>
>> Does the attached patch fix this issue?
>
>
> Not
Marek Olšák wrote:
Does the attached patch fix this issue?
Not properly - it fixes the invalid command stream but the output is not
quite right -
http://www.andyqos.ukfsn.org/vdpau-422-patched.png
Marek
On Mon, Aug 6, 2012 at 5:40 PM, Andy Furniss wrote:
Kernel is dcn card is rv790 -
Does the attached patch fix this issue?
Marek
On Mon, Aug 6, 2012 at 5:40 PM, Andy Furniss wrote:
> Kernel is dcn card is rv790 - vdpau csc/scale regressed.
>
> This only shows with 422 colour so most things work.
>
> commit 7c371f46958910dd2ca9487c89af1b72bbfdada9
> Author: Marek Olšák
> Dat
Kernel is dcn card is rv790 - vdpau csc/scale regressed.
This only shows with 422 colour so most things work.
commit 7c371f46958910dd2ca9487c89af1b72bbfdada9
Author: Marek Olšák
Date: Sat Jul 28 00:38:42 2012 +0200
r600g: make sure copying of all texture formats is accelerated
[drm:ra
101 - 135 of 135 matches
Mail list logo
