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
>
[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
-Isrc/gallium/drivers/r600 -I../src/gallium/drivers/r600 -Isrc -I../src
-
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
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 tesselation, no images, nor SSBOs), some things regress,
but some
This passes the arb_query_buffer-object-qbo test in piglit,
the coherent test is a bit less successful but some of that is
lacking support for indirect compute anyways.
I'm not going to enable GL4.5, as we haven't got CTS coverage
yet, but this is one of the last bits towards GL4.5 on cayman.
Dav
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
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 between stages.
The first 19 patches are the stuff I'm happy with, the
I've been running deqp-gles31 over the r600 ssbo/image code
it uses compute shaders, but I've found a few bugs in the in-tree
code, so just sending some fixes out for those first.
ssbo seems to pass all the tests, images have some heisenbug
where they pass sometimes and not others.
Dave.
___
There appears to be some bad interaction with the append/consume counters
on cayman (and compute shaders at least). I traced fglrx and it appears
it directly uses GDS memory.
This adds cayman specific paths to directly use GDS memory for these
atomics.
Dave.
_
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
I've been hacking on this on/off for quite a while now, and I think
I'm finally happy with where is has reached.
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!
If you have a cayman
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.
_
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.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mai
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
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 removes the AMDGPU header dependency
from r600 and I'm good with
These are just some minor prelim patches for the GL4.3 work, that
looked easy to split out.
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hello all,
Hardware; Radeon 6850HD,
Mesa: mesa 17.0.1 and git (sha 531887),
llvm:
4.0.0
Playing a bit around with the Unreal Editor I was confronted with the
same error message reported in #99349, i.e. "Failed to build shader
(translation from TGSI).
After some digging though the code I fou
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.
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.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https:/
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
___
Hey all,
I've pushed an updated version of the r600g tess support to my
r600g-tess-submit branch.
I'm in two minds whether we need to spam the list again,
I think I've included all the review feedback so far, thanks to
everyone that looked.
The major changes since the last posting are:
use 24-
I've had these sitting locally and heiko on #dri-devel found
they fixed some issues for him.
Marek provided me with some errata and this is the results of
implementing them.
It is nearly all fixes for r600 era hw.
Dave.
___
mesa-dev mailing list
mesa-
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
This adds multiple stream support for ARB_gpu_shader5, and one
other patch.
It doesn't expose ARB_gpu_shader5 yet, as I think we'd like
to try and get SB support for it into some sort of shape first.
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freede
Hi,
I am trying to integrate atomic counters to Mesa. I was able to do until
pipes (with the help of Marek and Ilia). How to integrate them to R600?
Thank you!
--
Regards,
*Aditya Atluri,*
*USA.*
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.
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
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 problem and I would like some advice.
So it ap
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
>
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 thing.)
One thing in particular I have not yet been able to figure out, is
I've lightly tested this, not piglit strength yet,
and it does require the kernel patch to work.
its also available in a branch in my repo r600-geom-shaders.
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/ma
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
The attached patches add two intrinsics to the R600 backend which are
necessary for geometry shader support in the radeonsi driver.
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
>From 8feb7201
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
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 to
grow the pool, then the resource associated with the buffer object is
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
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 is used - but I do not (yet) know why.
It works fine as long as I pass pointers to do
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
which should be convertible to a
REG_SEQUENCE.
Vincent
- Mail original -
> De : Tom Stellard
> À : llvm-comm...@cs.uiuc.edu
> Cc : mesa-dev@lists.freedesktop.org
> Envoyé le : Mardi 25 juin 2013 23h37
> Objet : [Mesa-dev] R600 Patches: KCache kernel argum
U::GROUP_BARRIER) {
> > return AluT_XYZW;
> >+}
>
> I'm not sure it'll factorize that much code ; R600Packetizer is called after
> cube/reduction op are lowered
> by R600Expand pass and thus the isVector/ReductionOp check is useless. I may
> have left some de
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,
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, UREM, XOR
Once that's done, the setOperationAction(op,type,Expand) cal
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 now it still fails because it tries to copy a VGPR to
an SGPR, which is not
First patch fixes load/store for v2i32 on R600. Without this, the
other two will cause make check failures. I've verified the changes
using a Radeon 5400 (Cedar). Note that the previous custom
lowering of v2i32 store was causing silent data corruption.
The other two patches expand add/sub on SI
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,
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=64257
The other patch fix a typo that causes instructions not to use PV/PS
}
I'm not sure it'll factorize that much code ; R600Packetizer is called after
cube/reduction op are lowered
by R600Expand pass and thus the isVector/ReductionOp check is useless. I may
have left some debug code in
isSoloInstruction code though.
- Mail original -
> De : Tom Stellar
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.
>
>
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.
--
Earthling Michel Dänzer | http://www.amd.com
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
Hi,
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.
-Tom
>From 5b87402d1290df5ec8bdbe1333cadb5739a8c8bd Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Mon, 13 May 2013 21:50
> 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
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.
v2: Add tests for v4i32 data type.
___
mesa-dev mailing list
mesa-
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
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.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lis
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
Hi,
The attached patches modify the CodeEmitter to emit true ISA.
Previously, we were prefixing all instructions with an instruction type
byte.
Vincent did most of the work to convert the CodeEmitter to true ISA,
these patches are just the last few cleanups that are needed to finish
the project.
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
t help other users who will possibly hit
similar issues. Also at least in this case it looks rather like a
problem in r600g, so I'm cc'ing mesa-dev, r600-sb just made this issue
more noticeable because shader rebuilding with optimization requires
more time.
Using standard r600g, the cpu
debug this.
> >
> > - Lauri
> >
> > PS: I'm not sure if this should be public or not, I think you're the
> > only one working on it?
>
> Yes, I doubt that anyone else will work on it, on the other hand I think
> reporting this on the list might hel
e
only one working on it?
Yes, I doubt that anyone else will work on it, on the other hand I think
reporting this on the list might help other users who will possibly hit
similar issues. Also at least in this case it looks rather like a
problem in r600g, so I'm cc'ing mesa-dev, r600-sb ju
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
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.
- Lauri
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http
Hi list
The recently added r600 sb backend fails to build on GCC < 4.3, since
it uses binary constants (0b0101).
Is the GCC version dependency intentional, or should the constants be
changed to int/hex?
- Lauri
___
mesa-dev mailing list
mesa-dev@lists.
1 - 100 of 135 matches
Mail list logo
