Am Samstag, den 28.11.2020, 02:46 +0100 schrieb Dieter Nützel:
> [48/179] Compiling C++ object
> src/gallium/drivers/r600/libr600.a.p/sfn_sfn_shader_fragment.cpp.o
> FAILED:
> src/gallium/drivers/r600/libr600.a.p/sfn_sfn_shader_fragment.cpp.o
> ccache c++ -Isrc/gallium/drivers/r600/libr600.a.p
>
Am Donnerstag, den 28.11.2019, 13:22 +1000 schrieb Dave Airlie:
> On Wed, 27 Nov 2019 at 21:08, Gert Wollny
> wrote:
> >
> > Before that I'd like to un-tabbify the whole r600 driver code,
> > because all the other parts of mesa I've been touching use spaces,
> > and it makes it more convenient to
On Wed, 27 Nov 2019 at 21:08, Gert Wollny wrote:
>
> Hello Dave,
>
> I was wondering how much interest you still have in R600? I'm preparing
> to start feeding my NIR work as MRs to continue my work in-tree. It is
> currently only for Evergreen and still far from feature parity
> with TGSI (no tes
Hi Dave,
Am Mittwoch, den 10.01.2018, 16:48 +1000 schrieb Dave Airlie:
> This is an attempt to add tessellation support to the SB backend.
>
I tried to dig a bit more in the failing piglits, specifically
"1in-1out" that passed with your WIP branch form Jan/9.
Now, with sb it fails by drawing
Am Mittwoch, den 10.01.2018, 16:48 +1000 schrieb Dave Airlie:
> This is an attempt to add tessellation support to the SB backend.
>
> The main things needed are GDS access which is used for tess
> factor storage (also used for atomic counters), and LDS access
> which is needed to pass all the data
Am Mittwoch, den 15.11.2017, 10:11 +1000 schrieb Dave Airlie:
>
> It's not 100% on piglits, but it's quite close, and better than fglrx
> does, so I'd probably prefer to land it before doing too much more
> destructive hacking on it!
I ran the piglits shader set on barts - no regressions, and all
For the series:
Reviewed-by: Nicolai Hähnle
On 01.11.2017 00:32, Dave Airlie wrote:
These are just some misc patches from the road to GL4.3 patches,
They don't do anything on their own, just cleanly improve the assembler
some state setting.
Dave.
_
On Fri, 2017-06-16 at 12:48 +0100, Emil Velikov wrote:
> On 15 June 2017 at 14:03, Aaron Watry wrote:
> > Hey all,
> >
> > We haven't landed the fixes to break the r600g dependency on AMDGPU yet.
> > I'm headed out of town for a long weekend and don't feel like risking the
> > push before being g
On 15 June 2017 at 14:03, Aaron Watry wrote:
> Hey all,
>
> We haven't landed the fixes to break the r600g dependency on AMDGPU yet.
> I'm headed out of town for a long weekend and don't feel like risking the
> push before being gone for five days.
>
> I've got a v3 of Emil's patch 4/5 that remove
On Wed, Apr 06, 2016 at 10:40:50PM +0100, Dave Airlie wrote:
> This probably should have been cleaned up before merging, but we
> were a bit lax with it. This is a bunch of cleanups and changes,
> that make adding ARB_compute_support less of a task.
>
Acked-by: Tom Stellard
> Dave.
>
> ___
Nice cleanup. This series is,
Reviewed-by: Edward O'Callaghan
On 2016-04-07 07:40, Dave Airlie wrote:
This probably should have been cleaned up before merging, but we
were a bit lax with it. This is a bunch of cleanups and changes,
that make adding ARB_compute_support less of a task.
Dave.
Hi,
On Fri, Dec 4, 2015 at 6:19 AM, Dave Airlie wrote:
> Hey all,
>
> I've pushed an updated version of the r600g tess support to my
> r600g-tess-submit branch.
FWIW:
Tested-by: Grazvydas Ignotas
on JUNIPER XT with heaven and piglit, no issues noticed.
Gražvydas
___
This patch series is:
Reviewed-by: Edward O'Callaghan
P.S. thanks for polishing it Dave!
--
Edward O'Callaghan
edward.ocallag...@koparo.com
On Tue, Aug 25, 2015, at 11:18 AM, Dave Airlie wrote:
> This adds multiple stream support for ARB_gpu_shader5, and one
> other patch.
>
> It doesn't
On 12/16/2014 05:44 AM, Dave Airlie wrote:
On 16 December 2014 at 08:59, Vadim Girlin wrote:
On 12/16/2014 01:30 AM, Dave Airlie wrote:
New patch is attached, the only difference is in the sb_sched.cpp (it
disables copy coalescing for some "unsafe" cases, so it may leave more
MOVs
than prev
On 16 December 2014 at 08:59, Vadim Girlin wrote:
> On 12/16/2014 01:30 AM, Dave Airlie wrote:
>
>
>
> New patch is attached, the only difference is in the sb_sched.cpp (it
> disables copy coalescing for some "unsafe" cases, so it may leave more
> MOVs
> than previously
On 12/16/2014 01:30 AM, Dave Airlie wrote:
New patch is attached, the only difference is in the sb_sched.cpp (it
disables copy coalescing for some "unsafe" cases, so it may leave more
MOVs
than previously, but I don't think there will be any noticeable effect on
performance).
So far I don't se
>>>
>>>
>>> New patch is attached, the only difference is in the sb_sched.cpp (it
>>> disables copy coalescing for some "unsafe" cases, so it may leave more
>>> MOVs
>>> than previously, but I don't think there will be any noticeable effect on
>>> performance).
>>>
>>> So far I don't see any proble
On 12/12/2014 05:28 PM, Alex Deucher wrote:
On Wed, Dec 10, 2014 at 6:50 AM, Vadim Girlin wrote:
On 12/09/2014 07:39 AM, Vadim Girlin wrote:
On 12/09/2014 05:18 AM, Dave Airlie wrote:
On 8 December 2014 at 20:41, Vadim Girlin wrote:
On 12/06/2014 07:13 AM, Vadim Girlin wrote:
On 12/04
On Wed, Dec 10, 2014 at 6:50 AM, Vadim Girlin wrote:
> On 12/09/2014 07:39 AM, Vadim Girlin wrote:
>>
>> On 12/09/2014 05:18 AM, Dave Airlie wrote:
>>>
>>> On 8 December 2014 at 20:41, Vadim Girlin wrote:
On 12/06/2014 07:13 AM, Vadim Girlin wrote:
>
>
> On 12/04/2014 01:43
On 12/09/2014 07:39 AM, Vadim Girlin wrote:
On 12/09/2014 05:18 AM, Dave Airlie wrote:
On 8 December 2014 at 20:41, Vadim Girlin wrote:
On 12/06/2014 07:13 AM, Vadim Girlin wrote:
On 12/04/2014 01:43 AM, Dave Airlie wrote:
Hi Vadim,
I've been looking with Glenn's help into a bug in sb for
On 12/09/2014 05:18 AM, Dave Airlie wrote:
On 8 December 2014 at 20:41, Vadim Girlin wrote:
On 12/06/2014 07:13 AM, Vadim Girlin wrote:
On 12/04/2014 01:43 AM, Dave Airlie wrote:
Hi Vadim,
I've been looking with Glenn's help into a bug in sb for a couple of
weeks now triggered by a change
On 8 December 2014 at 20:41, Vadim Girlin wrote:
> On 12/06/2014 07:13 AM, Vadim Girlin wrote:
>>
>> On 12/04/2014 01:43 AM, Dave Airlie wrote:
>>>
>>> Hi Vadim,
>>>
>>> I've been looking with Glenn's help into a bug in sb for a couple of
>>> weeks now triggered by a change in how GLSL generates s
On 9 December 2014 at 10:25, Dave Airlie wrote:
> On 8 December 2014 at 20:41, Vadim Girlin wrote:
>> On 12/06/2014 07:13 AM, Vadim Girlin wrote:
>>>
>>> On 12/04/2014 01:43 AM, Dave Airlie wrote:
Hi Vadim,
I've been looking with Glenn's help into a bug in sb for a couple of
>
On 8 December 2014 at 20:41, Vadim Girlin wrote:
> On 12/06/2014 07:13 AM, Vadim Girlin wrote:
>>
>> On 12/04/2014 01:43 AM, Dave Airlie wrote:
>>>
>>> Hi Vadim,
>>>
>>> I've been looking with Glenn's help into a bug in sb for a couple of
>>> weeks now triggered by a change in how GLSL generates s
On 12/06/2014 07:13 AM, Vadim Girlin wrote:
On 12/04/2014 01:43 AM, Dave Airlie wrote:
Hi Vadim,
I've been looking with Glenn's help into a bug in sb for a couple of
weeks now triggered by a change in how GLSL generates switch
statements.
I understand you probably aren't too interested in r600
On 12/06/2014 08:01 AM, Matt Turner wrote:
On Fri, Dec 5, 2014 at 8:56 PM, Vadim Girlin wrote:
On 12/06/2014 07:50 AM, Matt Turner wrote:
On Fri, Dec 5, 2014 at 8:13 PM, Vadim Girlin
wrote:
I suspect we should rather get rid of such loops somehow, i.e. convert to
something else, the loop t
On Fri, Dec 5, 2014 at 8:56 PM, Vadim Girlin wrote:
> On 12/06/2014 07:50 AM, Matt Turner wrote:
>>
>> On Fri, Dec 5, 2014 at 8:13 PM, Vadim Girlin
>> wrote:
>>>
>>> I suspect we should rather get rid of such loops somehow, i.e. convert to
>>> something else, the loop that never repeats is not re
On 12/06/2014 07:50 AM, Matt Turner wrote:
On Fri, Dec 5, 2014 at 8:13 PM, Vadim Girlin wrote:
I suspect we should rather get rid of such loops somehow, i.e. convert to
something else, the loop that never repeats is not really a loop anyway.
AFAICS "continue" is not supported in switch statemen
On Fri, Dec 5, 2014 at 8:13 PM, Vadim Girlin wrote:
> I suspect we should rather get rid of such loops somehow, i.e. convert to
> something else, the loop that never repeats is not really a loop anyway.
> AFAICS "continue" is not supported in switch statements according to GLSL
> specs, so the loo
On 12/04/2014 01:43 AM, Dave Airlie wrote:
Hi Vadim,
I've been looking with Glenn's help into a bug in sb for a couple of
weeks now triggered by a change in how GLSL generates switch
statements.
I understand you probably aren't too interested in r600g but I believe
I'm hitting a design level pr
On Thu, Apr 10, 2014 at 03:24:32PM +, Dorrington, Albert wrote:
> I am having an issue with a memory leak in an OpenCL program I am testing.
> In the program I call the same kernel repeatedly, for every pixel in an
> image. (Probably not the most efficient code, but it is a learning/testing
>
On Fri, Jan 24, 2014 at 03:17:04PM +0900, Michel Dänzer wrote:
>
> The attached patches add two intrinsics to the R600 backend which are
> necessary for geometry shader support in the radeonsi driver.
>
Patch 1 and v2 of Patch 2 are:
Reviewed-by: Tom Stellard
-Tom
>
> --
> Earthling Michel
On Mon, Jan 20, 2014 at 09:32:11PM +, Hrustich, John wrote:
> The compute memory pool used by the gallium r600 driver seems to be
> problematic. The pool looks to be a single radeon buffer object. There
> could be multiple maps set up into that single buffer object. If there is a
> need t
On Mit, 2013-07-10 at 08:15 -0700, Tom Stellard wrote:
> On Wed, Jul 10, 2013 at 12:32:25PM +0200, Michel Dänzer wrote:
> > On Fre, 2013-06-28 at 14:37 -0700, Tom Stellard wrote:
> > > On Wed, Jun 19, 2013 at 06:28:21PM +0200, Michel Dänzer wrote:
> > > >
> > > > These patches implement enough of
On Wed, Jul 10, 2013 at 12:32:25PM +0200, Michel Dänzer wrote:
> On Fre, 2013-06-28 at 14:37 -0700, Tom Stellard wrote:
> > On Wed, Jun 19, 2013 at 06:28:21PM +0200, Michel Dänzer wrote:
> > >
> > > These patches implement enough of local memory support to allow radeonsi
> > > to use that for comp
On Fre, 2013-06-28 at 14:37 -0700, Tom Stellard wrote:
> On Wed, Jun 19, 2013 at 06:28:21PM +0200, Michel Dänzer wrote:
> >
> > These patches implement enough of local memory support to allow radeonsi
> > to use that for computing derivatives, as suggested by Tom.
> >
> > They also almost allow t
Hi Tom,
> All these patches look good to me, but #2 and #6 should have a test case
> with them. If you resubmit these patches with test cases, I will push the
> entire series.
I have attached an updated patchset. I have added a test case to patch #2 and
#6. I have also replaced the scalar move
On Tue, Jul 02, 2013 at 10:44:10AM +0200, Niels Ole Salscheider wrote:
> Hi,
>
> the attached patches add initial support for double precision operations on
> Southern Islands cards.
>
> Some expressions containing multiple double precision kernel arguments cause
> llvm to run until all memory
On Wed, Jun 19, 2013 at 06:28:21PM +0200, Michel Dänzer wrote:
>
> These patches implement enough of local memory support to allow radeonsi
> to use that for computing derivatives, as suggested by Tom.
>
> They also almost allow test/CodeGen/R600/local-memory.ll to generate
> code for SI. Right n
The whole serie is : reviewed-by:Vincent Lejeune
In a future patch we might also remove the ISD::BUILD_VECTOR case in the
Select() function and use
a tablegen pattern ; I wrote it because we lowered r600.load.input intrinsic to
a raw register ; however now
we lower it to a copy from a register
Hi Vincent,
Here is an updated version of patch #3.
-Tom
On Fri, Jun 14, 2013 at 08:35:03AM -0700, Vincent Lejeune wrote:
> Hi,
>
> Thank for your work on this !
> Patch 2, 4 and 5 have my rb.
>
>
> >diff --git a/lib/Target/R600/R600InstrInfo.cpp
> >b/lib/Target/R600/R600InstrInfo.cpp
> >ind
On Thu, Jun 20, 2013 at 06:43:38PM -0500, Aaron Watry wrote:
> This series is intended to bring SI closer to evergreen when it comes to
> support for v2i32/v4i32 integer operations.
>
> It adds support for expanding the following v2i32/v4i32 operations on SI:
> AND, MUL, OR, SHL, SRL, ASHR, UDIV,
On Mon, Jun 17, 2013 at 06:43:09AM -0700, Vincent Lejeune wrote:
> Hi,
>
> these patches fix 2 bugs in R600 backend.
> The first one use the rv710/rv730 correct encoding for TEX clause with more
> than 8 instructions.
> This bug has been spoted there :
>
> https://bugs.freedesktop.org/show_bug.
On Mon, Jun 17, 2013 at 9:43 AM, Vincent Lejeune wrote:
> Hi,
>
> these patches fix 2 bugs in R600 backend.
> The first one use the rv710/rv730 correct encoding for TEX clause with more
> than 8 instructions.
> This bug has been spoted there :
>
> https://bugs.freedesktop.org/show_bug.cgi?id=6425
Hi,
Thank for your work on this !
Patch 2, 4 and 5 have my rb.
>diff --git a/lib/Target/R600/R600InstrInfo.cpp
>b/lib/Target/R600/R600InstrInfo.cpp
>index b9da74c..6de47f7 100644
>--- a/lib/Target/R600/R600InstrInfo.cpp
>+++ b/lib/Target/R600/R600InstrInfo.cpp
>@@ -133,6 +133,12 @@ bool R600Ins
On Wed, Jun 12, 2013 at 06:37:39PM -0700, Matt Arsenault wrote:
> On 06/12/2013 05:42 PM, Tom Stellard wrote:
> >Hi,
> >
> >The attached patches add support for local address space on
> >Evergreen / Northern Islands GPUs.
> >
> >Please Review.
> >
> >-Tom
> > + def int_AMDGPU_barrier_local : Intr
On 06/12/2013 05:42 PM, Tom Stellard wrote:
Hi,
The attached patches add support for local address space on
Evergreen / Northern Islands GPUs.
Please Review.
-Tom
> + def int_AMDGPU_barrier_local : Intrinsic<[], [], []>;
You probably want to mark this as IntrReadMem to try to avoid reorderi
On Sam, 2013-06-08 at 20:08 -0400, Tom Stellard wrote:
> On Fri, Jun 07, 2013 at 05:48:05PM -0700, Tom Stellard wrote:
> > On Fri, Jun 07, 2013 at 05:24:42PM +0200, Michel Dänzer wrote:
> > >
> > > @@ -1544,6 +1562,26 @@ def : Pat <
> > > sub3)
> > > >;
> > >
> > > +class DD
On Fri, Jun 07, 2013 at 05:48:05PM -0700, Tom Stellard wrote:
> On Fri, Jun 07, 2013 at 05:24:42PM +0200, Michel Dänzer wrote:
> >
> > The most important difference to the previous version of these is that
> > whole quad mode is now enabled and M0 initialized appropriately for the
> > LDS instruct
On Fri, Jun 07, 2013 at 05:24:42PM +0200, Michel Dänzer wrote:
>
> The most important difference to the previous version of these is that
> whole quad mode is now enabled and M0 initialized appropriately for the
> LDS instructions, which now allows all of the relevant piglit tests to
> pass.
>
Hi
On Fri, Jun 07, 2013 at 05:24:42PM +0200, Michel Dänzer wrote:
>
> The most important difference to the previous version of these is that
> whole quad mode is now enabled and M0 initialized appropriately for the
> LDS instructions, which now allows all of the relevant piglit tests to
> pass.
>
>
On Mit, 2013-05-15 at 14:26 -0700, Tom Stellard wrote:
>
> The attached patches add some new patterns and instructions for SI and
> are a prerequisite for more invasive compute shader changes that I'm
> working on.
>
> Please Review.
The SI changes are
Reviewed-by: Michel Dänzer
--
Earthlin
On Thu, May 16, 2013 at 08:21:36AM -0700, Vincent Lejeune wrote:
> Hi,
>
>
> >-- next part --
> >>From dc547a89dac5039ce521f3c27fb23346251d488d Mon Sep 17 00:00:00 2001
> >>>From: Tom Stellard
> >Date: Tue, 7 May 2013 16:26:26 -0400
> >Subject: [PATCH 4/7] R600: Swap the
Hi,
>-- next part --
>>From dc547a89dac5039ce521f3c27fb23346251d488d Mon Sep 17 00:00:00 2001 >From:
>>Tom Stellard
>Date: Tue, 7 May 2013 16:26:26 -0400
>Subject: [PATCH 4/7] R600: Swap the legality of rotl and rotr
>
>The hardware supports rotr and not rotl.
>---
> lib
> From 8aa41148651150eb19332436c76fe490d4b54b1e Mon Sep 17 00:00:00 2001
> From: Vincent Lejeune
> Date: Sun, 12 May 2013 16:29:50 +0200
> Subject: [PATCH 1/2] R600: Rename 128 bit registers.
>
> Almost all instructions that takes a 128 bits reg as input (fetch, export...)
> have the abilities
On Sun, May 12, 2013 at 07:41:21AM -0700, Vincent Lejeune wrote:
> Hi,
> Patches 2 and 3 factorizes some code from the backend. Patch 3 should avoid
> some recomputation too, which shouldn't hurt.
> Patch 4 and 5 rework how textures are handled in our backend. It replaces
> TGSI like intrinsic (i
On Mon, May 06, 2013 at 07:35:42PM -0500, Aaron Watry wrote:
> These two patches fix a number of piglit OpenCL test failures on my
> HD6850 (Barts).
>
> There are no piglit CL test regressions and the llvm make check runs
> without any unexpected failures.
>
Hi Aaron,
These patches look good to
Reviewed-by:Vincent Lejeune
- Mail original -
> De : Tom Stellard
> À : Vincent Lejeune
> Cc : "llvm-comm...@cs.uiuc.edu" ;
> "mesa-dev@lists.freedesktop.org"
> Envoyé le : Lundi 6 mai 2013 17h02
> Objet : Re: R600 Patchset: Emit true ISA
>
> On Sat, May 04, 2013 at 09:09:25AM -0700,
On Sat, May 04, 2013 at 09:09:25AM -0700, Vincent Lejeune wrote:
> Hi,
>
> Thank for doing this.
> Patches 1 2 and 3 have my rb.
> For patch 4:
>
Hi Vincent,
Attached is an updated version of patch 4.
-Tom
> >@@ -125,9 +106,7 @@ MCCodeEmitter *llvm::createR600MCCodeEmitter(const
> >MCInstrIn
This series, and the associated mesa changes are all:
Tested-By: Aaron Watry
--Aaron
On Fri, May 3, 2013 at 5:53 PM, Tom Stellard wrote:
> Hi,
>
> The attached patches modify the CodeEmitter to emit true ISA.
> Previously, we were prefixing all instructions with an instruction type
> byte.
>
>
Hi,
Thank for doing this.
Patches 1 2 and 3 have my rb.
For patch 4:
>@@ -125,9 +106,7 @@ MCCodeEmitter *llvm::createR600MCCodeEmitter(const
>MCInstrInfo &MCII,
>
> void R600MCCodeEmitter::EncodeInstruction(const MCInst &MI, raw_ostream &OS,
>SmallVectorI
On Fri, 03 May 2013 01:27:27 +0400
Vadim Girlin wrote:
> I'm almost sure that the same issue that you have with glxgears affects
> your app too, so you might want to wait until we resolve the problem
> with gears, possibly this will solve other rendering issues as well.
>
...
>
> By the way, I
On Fri, 03 May 2013 00:39:09 +0400
Vadim Girlin wrote:
> I see some issues issues in the dump, looks like compiler doesn't
> zero-initialize some data (particularly alu_node::bc) in cases where I
> expect it. Possibly it's my bug, I'll look into it, but the data in
> question is definitely zer
On 05/02/2013 06:34 PM, Lauri Kasanen wrote:
On Thu, 02 May 2013 00:45:13 +0400
Vadim Girlin wrote:
On 05/01/2013 11:36 PM, Lauri Kasanen wrote:
Now that it built, I could test your optimizations in my own apps.
These are on current master 8eef6ad, on a RV710 (HD 4350 pci-e).
In one of my pr
On Thu, 02 May 2013 00:45:13 +0400
Vadim Girlin wrote:
> On 05/01/2013 11:36 PM, Lauri Kasanen wrote:
> > Now that it built, I could test your optimizations in my own apps.
> > These are on current master 8eef6ad, on a RV710 (HD 4350 pci-e).
> >
> > In one of my private apps, using R600_DEBUG=sb
On 05/01/2013 11:36 PM, Lauri Kasanen wrote:
Hi Vadim
Now that it built, I could test your optimizations in my own apps.
These are on current master 8eef6ad, on a RV710 (HD 4350 pci-e).
In one of my private apps, using R600_DEBUG=sb caused regressions: FPS
went from 28 to 7, the SSAO shader gav
On 05/01/2013 11:42 PM, Lauri Kasanen wrote:
Hi
Running "R600_DEBUG=sb glxgears" on a RV710 gives wrong output:
http://i40.tinypic.com/t7gx09.png
This is on current master, git-8eef6ad.
Let me know what you need to debug this.
Please send me the output with R600_DEBUG=sb,ps,vs
Vadim
___
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
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,
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
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
95 matches
Mail list logo
