default. It can be
> enabled with the environment variable R600_DEBUG=llvm.
>
> Cc: "10.1"
> Signed-off-by: Michel Dänzer
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/r600/r600_pipe.c | 6 +++---
> src/gallium/drivers/r600/r600_pipe.h | 2 +-
>
work most of the time because most of the SI tiling
> modes use the same number of banks.
Thanks for catching this.
Reviewed-by: Alex Deucher
I think the kernel could use a similar fix for the display setup.
Alex
>
> Signed-off-by: Michel Dänzer
> ---
> src/gallium/drivers/ra
On Sun, Apr 20, 2014 at 9:59 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> We forgot to set these bits.
>
> Cc: 10.1 mesa-sta...@lists.freedesktop.org
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/r600/r600_state.c | 6 --
> 1 file changed, 4 in
On Sun, Apr 20, 2014 at 9:59 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> Cc: 10.0 10.1 mesa-sta...@lists.freedesktop.org
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/r600/r600_hw_context.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/
On Sun, Apr 20, 2014 at 9:59 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> Cc: 10.0 10.1 mesa-sta...@lists.freedesktop.org
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/radeon/r600_texture.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/sr
On Sun, Apr 20, 2014 at 9:59 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> This fixes broken rendering in DOTA 2.
>
> Cc: 10.0 10.1 mesa-sta...@lists.freedesktop.org
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/r600/r600_blit.c | 6 ++
> 1 file changed,
On Sun, Apr 20, 2014 at 9:59 PM, Marek Olšák wrote:
> From: Marek Olšák
>
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/radeon/r600_texture.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/src/gallium/drivers/radeon/r600_texture.c
> b/sr
On Sun, Apr 20, 2014 at 9:59 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> Cc: mesa-sta...@lists.freedesktop.org
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/r600/evergreen_state.c | 24 -
> src/gallium/drivers/r600/r600_pipe.h | 31 ++
On Sun, Apr 20, 2014 at 9:59 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> Cc: 10.0 10.1 mesa-sta...@lists.freedesktop.org
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/r600/evergreen_state.c | 5 -
> src/gallium/drivers/r600/r600_state.c | 5 +
>
On Sun, Apr 20, 2014 at 9:59 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> Changing SX_MISC hangs RV740. When we're at it, let's use
> DX_RASTERIZATION_KILL
> on all R700 and later chipsets.
>
> Cc: 10.0 10.1 mesa-sta...@lists.freedesktop.org
Reviewed-by: Alex
From: Samuel Li
Signed-off-by: Samuel Li
Signed-off-by: Alex Deucher
---
lib/Target/R600/Processors.td | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/Target/R600/Processors.td b/lib/Target/R600/Processors.td
index fde4481..ce17d7c 100644
--- a/lib/Target/R600/Processors.td
+++ b
From: Samuel Li
Signed-off-by: Samuel Li
Signed-off-by: Alex Deucher
---
include/pci_ids/radeonsi_pci_ids.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/pci_ids/radeonsi_pci_ids.h
b/include/pci_ids/radeonsi_pci_ids.h
index 7b42d5e..5099c74 100644
--- a
From: Samuel Li
Signed-off-by: Samuel Li
Signed-off-by: Alex Deucher
---
src/gallium/drivers/radeon/r600_pipe_common.c | 2 ++
src/gallium/drivers/radeonsi/si_state.c | 2 ++
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 1 +
src/gallium/winsys/radeon/drm/radeon_winsys.h
On Fri, May 2, 2014 at 5:51 PM, Brian Paul wrote:
> I don't have time to investigate right now, but a recent Mesa commit seems
> to have broke some of our automated builds on Linux:
>
> With SCONS:
>
> scons: done reading SConscript files.
> scons: Building targets ...
> Compiling src/gallium/st
On Wed, May 14, 2014 at 3:32 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Bring it back in line with r600g. I broke this in the original radeonsi
> bringup. :(
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78537
> Signed-off-by: Michel Dänzer
CC stabl
This implements blit support using the partial blit
packets which properly handle subwindow blits. linear
<-> tiled blits aren't quite right and cause GPU page
faults in certain cases.
Signed-off-by: Alex Deucher
---
src/gallium/drivers/radeonsi/Makefile.sources | 1 +
src/gall
On Fri, May 30, 2014 at 11:31 AM, Bruno Jiménez wrote:
> The data has been extracted from:
> AMD Accelerated Parallel Processing OpenCL Programming Guide (rev 2.7)
> Appendix D: Device Parameters
You should add a query for the number of compute units to the
RADEON_INFO ioctl and then just ask the
On Sat, May 31, 2014 at 7:13 AM, Bruno Jimenez wrote:
> On Fri, 2014-05-30 at 19:33 -0400, Alex Deucher wrote:
>> On Fri, May 30, 2014 at 11:31 AM, Bruno Jiménez wrote:
>> > The data has been extracted from:
>> > AMD Accelerated Parallel Processing OpenCL
On Mon, Jun 2, 2014 at 7:34 PM, Bruno Jimenez wrote:
> On Mon, 2014-06-02 at 16:16 -0400, Alex Deucher wrote:
>> On Sat, May 31, 2014 at 7:13 AM, Bruno Jimenez wrote:
>> > On Fri, 2014-05-30 at 19:33 -0400, Alex Deucher wrote:
>> >> On Fri, May 30, 2014 at 11:31 A
On Sun, Apr 21, 2013 at 7:25 PM, Marek Olšák wrote:
> Although this might be useful for ARB_clear_buffer_object,
> I need it for initializating resources in r600g.
For the series:
Reviewed-by: Alex Deucher
Should probably go to 9.1 as well or disable cmask/htile on 9.1
Alex
> -
On Mon, Apr 22, 2013 at 11:24 PM, Tom Stellard wrote:
> From: Tom Stellard
>
> Buffer size should be in bytes not dwords.
For the series:
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/r600/evergreen_compute.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-
On Wed, Apr 24, 2013 at 7:38 AM, Marek Olšák wrote:
> You should also bump R600_NUM_ATOMS whenever you add a new atom with
> r600_init_atom. BTW, what does LS stand for?
LS = Local Shader
It's part of the hw pipeline for DX11/GL4
LS and CS (compute shader) resource are shared on evergreen asics.
2013 at 9:15 PM, wrote:
>> From: Alex Deucher
>>
>> Lighter weight then using streamout. Only evergreen
>> and newer asics support embedded data as src with
>> CP DMA.
>>
>> Signed-off-by: Alex Deucher
>> ---
>> src/gallium/drivers/r600/evergree
On Fri, Apr 26, 2013 at 5:51 AM, Christian König
wrote:
> From: Christian König
>
> That is just not supported by the hardware.
>
> Signed-off-by: Christian König
> ---
> src/gallium/drivers/r600/r600_pipe.c|2 +-
> src/gallium/drivers/r600/r600_pipe.h|3 +++
> src/gallium/drive
On Fri, Apr 26, 2013 at 9:26 AM, Christian König
wrote:
> From: Christian König
>
> That is just not supported by the hardware.
>
> v2: fix compare
>
> Signed-off-by: Christian König
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/r600/r600_pipe.c|
On Fri, Apr 26, 2013 at 1:21 PM, Tom Stellard wrote:
> From: Tom Stellard
For the series:
Reviewed-by: Alex Deucher
>
> ---
> src/gallium/drivers/r600/evergreen_compute.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/r60
On Tue, Apr 30, 2013 at 9:40 AM, Brian Paul wrote:
> On 04/27/2013 06:57 AM, Zack Rusin wrote:
>>
>> Technically it's legal for geometry shader to not emit any
>> vertices. It's silly, but perfectly legal, so lets make draw
>> stop crashing if it happens.
>>
>> Signed-off-by: Zack Rusin
>> ---
>>
On Thu, May 2, 2013 at 11:55 AM, Marek Olšák wrote:
> AFAIK, there are 16 fetch shader resources. These are the resource
> slots for r600:
>
> [offset .. +count]
> PS: 0 .. +160
> VS: 160 .. +160
> FS: 320 .. +16
> GS: 336 .. +160
It's bigger on evergreen:
PS: 0.. +176
VS: 176.. +160
GS: 336..
Just a reminder to all students and mentors planning to work on an
X.Org GSoC project this year, the deadline for applications is
tomorrow (May 3rd, 19:00 UTC). If you are a student planning to
apply, please submit your application by the deadline. If you are
planning to mentor a project and have
On Thu, May 2, 2013 at 11:40 PM, Zack Rusin wrote:
> gallium lies. buffer_size is not actually buffer_size but available
> size, which is 'buffer_size - buffer_offset' so by adding buffer
> offset we'd incorrectly compute overflow.
Maybe add a comment to that effect in the code?
Alex
>
> Signed
On Fri, May 3, 2013 at 9:30 AM, Vadim Girlin wrote:
> This patch results in lockups with Heaven on juniper for me.
Does dropping the surface_sync packet completely help? We shouldn't
need a surface_sync packet after a CACHE_FLUSH_AND_INV_EVENT packet
and prior to e5e4c07e7964a3258ed02b530bcdc24c
On Fri, May 3, 2013 at 9:55 AM, Lauri Kasanen wrote:
> Assigning a struct only copies the members - any padding is left as is.
>
> Thus this code:
>
> struct foo_t foo;
> foo = bar;
>
> leaves the padding of foo intact, ie uninitialized random garbage.
>
> This patch fixes constant shader recompil
On Mon, May 6, 2013 at 10:33 AM, Divick Kishore
wrote:
> Hi,
> I am trying to build s/w only mesa driver. It seems that the
> performance of software only renderer (compiled with
> --with-driver=xlib) is higher than that of h/w drivers. Could someone
> please help me understand what is causin
drm requirement when you commit? Other than that:
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/r600/evergreen_state.c | 17 +++-
> src/gallium/drivers/r600/evergreend.h |3 +++
> src/gallium/drivers/r600/r600_blit.c |6 +
> src/ga
On Thu, May 9, 2013 at 5:33 PM, Marek Olšák wrote:
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/r600/evergreen_state.c | 16
> src/gallium/drivers/r600/r600_asm.c|6 +++---
> src/gallium/drivers/r600/r600_asm.h|4 ++--
> src/
On Tue, May 21, 2013 at 6:12 PM, wrote:
> From: Roland Scheidegger
>
> This optimization disabled mask checks if the shader is simple enough.
> While this should work correctly, the problem is that it can hide real issues
> because shaders in practice are usually complex enough (8 instructions o
On Fri, May 31, 2013 at 6:54 PM, Roland Scheidegger wrote:
> Am 31.05.2013 23:43, schrieb srol...@vmware.com:
>> From: Roland Scheidegger
>>
>> Since pipe_surface already has all the necessary fields no interface
>> changes are necessary except adding a new shader semantic value
>> (TGSI_SEMANTIC
On Mon, Jun 3, 2013 at 3:22 AM, Siavash Eliasi wrote:
> Hello dear mesa developers,
>
> What is current status of hw_gl_select branch? Is there any reason keeping
> it back from being merged into the master branch?
IIRC, Brian wanted to review it a bit more, but I guess he never got
to it. It pr
On Wed, Jun 5, 2013 at 1:50 PM, Arnas Milaševičius wrote:
> Will it be approved or I need to resend this patch with a better commit
> massage?
Please resend a version 3 with an improved commit message. It's also
good to include a small list of changes between versions if you resend
the patch mul
On Thu, Jun 6, 2013 at 4:56 AM, Arnas Milasevicius wrote:
>
> Because draw_arrays() is only sued in state_tracker's st_draw_feedback.c
> file, I moved it from draw_pt.c to there and mate it static.
A couple of typos:
sued -> used
mate -> made
Also, please try and make your commit messages wrap
Candidate for the stable branches?
On Fri, Jun 7, 2013 at 5:58 AM, Marek Olšák wrote:
> Reviewed-by: Marek Olšák
>
> Marek
>
> On Fri, Jun 7, 2013 at 6:25 AM, Chia-I Wu wrote:
>>
>> Signed-off-by: Chia-I Wu
>> ---
>> src/gallium/auxiliary/util/u_vbuf.c |3 +++
>> 1 file changed, 3 inserti
On Fri, Jun 7, 2013 at 1:36 PM, Chia-I Wu wrote:
> On Fri, Jun 7, 2013 at 9:25 PM, Alex Deucher wrote:
>> Candidate for the stable branches?
> Ah, I already committed it. I will let it settle in master for a few
> days and cherry-pick it to 9.1, unless this is against some policy
er, Tom has had some strange
behavior with compute using VM and there are a number of strange bugs
on TN and cayman that may still be VM related.
Alex
>
> Marek
>
> On Mon, Jun 10, 2013 at 10:34 PM, wrote:
>> From: Alex Deucher
>>
>> Set env var RADEON_VA=0 to dis
ktop.org/show_bug.cgi?id=64257
> The other patch fix a typo that causes instructions not to use PV/PS register
> when R600Packetizers evaluates read port limitations.
> It prevents some bundling opportunities in some (not so frequent) situation.
Reviewed-by: Alex Deucher
___
S_0085F0_SMX_ACTION_ENA(1) |
>>> S_0085F0_FULL_CACHE_ENA(1);
>>> emit_flush = 1;
>>> }
>>> --
>>> 1.8.3
>>>
>>> _______
>>> mesa-dev mailing list
>>> mesa-dev@lists.
th flushing unbound CBs. I
think it should be ok. Martin, can you try the attached patch?
Alex
>
> Marek
>
> On Sun, Jun 23, 2013 at 7:41 PM, Alex Deucher wrote:
>> On Sat, Jun 22, 2013 at 11:53 AM, Martin Andersson
>> wrote:
>>> On Sat, Jun 22, 2013 at
On Sun, Jun 23, 2013 at 9:31 PM, Marek Olšák wrote:
> This might fix the lockups caused by colorbuffer flushes and it's generally
> the right thing to do. Untested.
Looks good to me.
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/r600/evergreen_compute.c | 13 ++
On Thu, Jun 27, 2013 at 12:57 AM, Tom Stellard wrote:
> From: Tom Stellard
>
For the series:
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/r300/Makefile.am |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/src/gallium/drivers/r300
On Sun, Jun 30, 2013 at 9:53 PM, Marek Olšák wrote:
> this also fixes the fast clear with multiple colorbuffers and each having
> a different format
Series is:
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/r600/r600_blit.c | 21 -
> 1 file changed
On Fri, Jan 31, 2014 at 7:05 AM, Marek Olšák wrote:
> I think we always flush the HDP cache after (before?) command submission.
>
The kernel flushes the HDP cache in the fence command sequence.
Alex
> This patch adds nothing new to the drivers - we have always had
> persistent buffer mappings f
On Mon, Feb 3, 2014 at 3:54 AM, Rogovin, Kevin wrote:
> Hi,
>
>> We can't do stencil blits with GLSL because no driver that uses meta can
>> do the GL_ARB_shader_stencil_export extension. For depth and color
>> blits, we can always write the values from the shader, and disable
>> writes to the bu
On Mon, Feb 3, 2014 at 5:33 AM, Christian König wrote:
> From: Christian König
>
> Without the correct feedback buffer size UVD runs
> into an error on each frame, reducing the maximum FPS.
>
> Signed-off-by: Christian König
Reviewed-by: Alex Deucher
Should probably also
the
> geometry tests, and I'd like to merge this soon, I think any remaining
> problems
> can be fixed in tree.
Other than a few minor comments, this series is:
Reviewed-by: Alex Deucher
Thank you to both you and Vadim for doing this!
Alex
On Mon, Feb 3, 2014 at 6:53 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> This is my first attempt at enabling r600/r700 geometry shaders,
> the basic tests pass on both my rv770 and my rv635,
>
> It requires this kernel patch:
> http://www.spinics.net/lists/dri-devel/msg52745.html
>
> Signed-of
On Wed, Feb 5, 2014 at 4:23 PM, Dave Airlie wrote:
> Since r600g in master now has GL 3.3 support and it would be really
> good if we could provide a consistent 3.3 support level (not looking
> at you sandybridge).
>
> So I'd like to request that I can backport the r600g specific patches
> to enab
On Fri, Feb 7, 2014 at 12:34 AM, Connor Abbott wrote:
> Hi,
>
> So I believe that we can all agree that the tree-based representation
> that GLSL IR currently uses for shaders needs to go. For the benefit
> of those that didn't watch Ian Romanick's talk at FOSDEM, I'll
> reiterate some of the prob
On Thu, Feb 6, 2014 at 7:08 PM, Joey Reid wrote:
> the folder:
> http://www.x.org/docs/AMD/
>
> has an outdated version of Southern Islands Series Instruction Set
> Architecture. The latest version can be found here:
> http://developer.amd.com/wordpress/media/2012/12/AMD_Southern_Islands_Instructi
Signed-off-by: Alex Deucher
Cc: "10.1" "10.0"
---
src/gallium/drivers/r600/r600_pipe.c | 4 ++--
src/gallium/drivers/radeon/r600_pipe_common.c | 2 +-
src/gallium/drivers/radeon/r600_pipe_common.h | 2 +-
src/gallium/drivers/radeon/r600_texture.c | 2 +-
4 files c
On Thu, Feb 13, 2014 at 9:09 AM, sathishkumar sivagurunathan
wrote:
> Hi,
>
>I am trying to check the graphics card that I have.. From internet
> search, I found the following command lists the graphics card in a system.
>
> 1) sudo lshw -C display; lsb_release -a; uname -a; xrandr
>
> The out
On Wed, Feb 12, 2014 at 2:21 PM, Marek Olšák wrote:
> Acked-by: Marek Olšák
>
> Please don't close the FDO bugs after this is committed.
I don't plan to.
Thanks,
Alex
>
> Marek
>
> On Wed, Feb 12, 2014 at 6:20 PM, Alex Deucher wrote:
>> Change the fla
On Wed, Feb 19, 2014 at 6:09 PM, Tom Stellard wrote:
> ---
> src/gallium/auxiliary/util/u_math.h | 10 ++
> 1 file changed, 10 insertions(+)
For the series:
Reviewed-by: Alex Deucher
>
> diff --git a/src/gallium/auxiliary/util/u_math.h
> b/src/gallium/auxiliary/uti
On Fri, Feb 21, 2014 at 12:22 PM, Dorrington, Albert
wrote:
> I have started getting the errors shown below while experimenting with the
> openCL code:
>
>
>
> I am using a recent pull of Mesa (a 10.1-devel trunk pull, about a week old
> or so I think) and have updated to libdrm 2.4.52
>
> I'm stu
On Mon, Feb 24, 2014 at 4:53 PM, Tom Stellard wrote:
> This prevents clover from using unsupported devices.
Candidate for stable?
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/r600/r600_pipe.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff -
On Sun, Mar 2, 2014 at 8:25 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> Also translate the Y__X swizzle.
For the series:
Reviewed-by: Alex Deucher
Candidate for the stable trees as part of the fix for srgb dark rendering?
> ---
> src/gallium/drivers/radeon/r600_pip
On Sun, Mar 16, 2014 at 12:46 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> Also rewrite the comment for it to be readable and reorder the code.
Reviewed-by: Alex Deucher
> ---
> src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 23 +--
> 1 file chan
On Mon, Mar 17, 2014 at 11:36 AM, Dorrington, Albert
wrote:
> I'm curious if there is any way to reset/restart the video card via Mesa or
> the libdrm drivers?
>
>
>
> I'm currently doing development against the OpenCL drivers, and getting the
> video card into a state where is will not respond.
>
On Wed, Dec 10, 2014 at 5:40 AM, Marek Olšák wrote:
> bpe is in bytes, not bits, so you're overallocating the size 8 times.
> No wonder it works.
>
> As far as I can see, FMASK allocation is the same on R600 and
> Evergreen. Since the allocator accepts bpe in bytes, I multiplied
> nr_samples with
On Wed, Dec 10, 2014 at 5:08 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> This fixes incorrect rendering in Unreal Engine demos.
> I don't know why it's called "dx10 clamp mode". MSDN doesn't mention it.
Reviewed-by: Alex Deucher
Stable?
Does r600g need
real apps.
>>>>
>>> This does seem to fix the problems in piglit, and looks close to what
>>> I was attempting but written by someone who knows what they are doing :-)
>>>
>>> What is the sb_sched.cpp change for at the end for?
>>
>>
>&
On Fri, Dec 19, 2014 at 8:13 AM, David Heidelberg wrote:
> Signed-off-by: David Heidelberg
Reviewed-by: Alex Deucher
> ---
> src/gallium/state_trackers/nine/device9.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/nine/
On Fri, Dec 19, 2014 at 8:11 AM, David Heidelberg wrote:
> Same as ARL, just has extra rounding.
> Useful for st/nine.
>
> Tested-by: Pavel Ondračka
> Reviewed-by: Marek Olšák
> Signed-off-by: David Heidelberg
Reviewed-by: Alex Deucher
> ---
> src/galli
On Wed, Jan 7, 2015 at 6:58 AM, Marek Olšák wrote:
> How about the attached patch?
Reviewed-by: Alex Deucher
>
> Marek
>
> On Wed, Jan 7, 2015 at 1:23 AM, Tom Stellard wrote:
>> On Wed, Jan 07, 2015 at 01:13:37AM +0100, Marek Olšák wrote:
>>> Neither. It'
On Wed, Jan 7, 2015 at 11:29 AM, Marek Olšák wrote:
> On Wed, Jan 7, 2015 at 2:42 PM, Aditya Avinash
> wrote:
>> Hi,
>> Sounds great but, do you think a separate buffer pipe is required for this?
>> Changing Constant buffer to a generic buffer (with alu+load+store) can help.
>
> No, constant buf
On Wed, Jan 7, 2015 at 8:19 PM, Dave Airlie wrote:
> Okay I've been doing some further FMASK studies empirically, dumping
> the fmask after rendering to an MSAA surface,
>
> it appears on r600 at 8xMSAA, every 8x8 tile requires 128 bytes of
> storage, that is used depending on the value in the CMA
On Thu, Jan 8, 2015 at 3:37 PM, Marek Olšák wrote:
> On Thu, Jan 8, 2015 at 8:41 PM, Tom Stellard wrote:
>> On Thu, Jan 08, 2015 at 07:51:58PM +0100, Marek Olšák wrote:
>>> On Thu, Jan 8, 2015 at 7:17 PM, Tom Stellard wrote:
>>> > On Thu, Jan 08, 2015 at 07:00:11PM +0100, Marek Olšák wrote:
>>>
we don't over allocate things too much,
> once this fix in place we can nuke the extra multiplier in mesa.
>
> Signed-off-by: Dave Airlie
Reviewed-by: Alex Deucher
> ---
> radeon/radeon_surface.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/radeon/ra
radeon does not support TripleBuffering so we do not have to
> worry about perserving the flags when injecting the third buffer.
>
> Signed-off-by: Chris Wilson
> Cc: Dave Airlie
> Cc: Jerome Glisse
> Cc: Alex Deucher
> Cc: Michel Dänzer
Reviewed-by: Alex Deuch
Reviewed-by: Alex Deucher
On Mon, Jan 28, 2019 at 10:56 AM Marek Olšák wrote:
>
> From: Marek Olšák
>
> ---
> src/amd/common/ac_llvm_util.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/amd/common/ac_llvm_util.c b/src/amd/commo
On Sat, Feb 2, 2019 at 4:13 AM Jean-Dominique Frattini
wrote:
>
> Hello,
>
> I am on Debian Linux testing. And after an update (firmware-amd-graphics,
> xserver-xorg-video-amdgup and Mesa), my program often raises this error
> message:
>
> amdgpu: The CS has been cancelled because the context is
On Thu, Feb 7, 2019 at 2:47 PM Axel Davy wrote:
>
> On 07/02/2019 02:22, Marek Olšák wrote:
> >
> > + bool use_sdma_upload = sscreen->info.has_dedicated_vram &&
> > sctx->dma_cs && debug_get_bool_option("SDMA", true);
> > + sctx->b.const_uploader = u_upload_create(&sctx->b, 256 * 1024,
>
On Fri, Mar 1, 2019 at 10:11 AM Mike Lothian wrote:
>
> Hi
>
> What do you mean by kernel driver version? It doesn't seem to match up
> with a kernel version or a DC Version
It's not the DC version or the kernel version. There is a drm
interface to get the drm driver version so that userspace ca
I don't remember seeing your message, but you can find details about EVoC here:
https://www.x.org/wiki/XorgEVoC/
Basically, it's similar to GSoC. The prospective student picks a
project, gets involved in the project (to learn the code and make some
simple changes to show you understand it) and th
On Tue, Sep 1, 2015 at 3:04 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> This must be done before exporting a buffer as dmabuf fds, because
> we lose track of who is using it and can't trust the reference counter.
>
> Cc: 11.0
For the series:
Reviewed-by: Alex Deucher
On Fri, Sep 4, 2015 at 3:47 PM, Bas Nieuwenhuizen
wrote:
> This patch series enables delta color compression (DCC) for Vulcanic
> Islands GPU's. This should reduce memory bandwidth to increase
> performance.
>
> I have found no documentation on this feature, so most of the work is
> based on guess
On Sun, Sep 6, 2015 at 10:13 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> This fixes corruption in Unigine Heaven on VI
>
> Cc: 11.0
For the series:
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/radeonsi/si_pipe.c | 4 +---
> 1 file changed, 1 insertion(+),
On Sun, Sep 6, 2015 at 4:28 AM, Lauri Kasanen wrote:
> On Sat, 5 Sep 2015 23:29:05 +
> Albert Freeman wrote:
>
>> The reply from Eric Anholt made two suggestions that should not be
>> difficult to implement for someone who made the patch in the first
>> place. Why would code be committed when
t; Reviewed-by: Boyan Ding
>
> Courtesy ping. If we don't get any objections/comments, over the next
> few days I will be pushing these patches.
>
> As mentioned, things just work and there are no regressions (according
> to a full piglit r
On Wed, Sep 23, 2015 at 3:57 PM, Leo Liu wrote:
> if app pass 0 as frame_rate_num, it should not be encoded to the VUI.
>
> Signed-off-by: Leo Liu
> Reviewed-by: Alex Deucher
> Reviewed-by: Christian König
> Cc: "10.6"
11.0 should be cc'ed as well.
Alex
&g
On Tue, Sep 29, 2015 at 1:19 PM, Romain Failliot
wrote:
> @glenn:so, if I sum up, even though ARB_gpu_shader5 is marked unsupported
> for R600 here
> (https://secure.freedesktop.org/~imirkin/glxinfo/glxinfo.html), it doesn't
> mean that it is really unsupported for this driver.
>
> @albert: thanks
On Tue, Sep 29, 2015 at 1:29 PM, Romain Failliot
wrote:
> Le 29 sept. 2015 7:22 PM, "Ilia Mirkin" a écrit :
>> R600/R700 will never support ARB_gpu_shader5. Evergreen and NI
>> families (also driven by the r600g driver) will gain support for it in
>> due time.
>
> Aaaah I think I understand my mi
On Tue, Oct 6, 2015 at 2:13 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> Signed-off-by: Ian Romanick
Assuming the pointer is set correctly as per Brian's comments, this patch is:
Reviewed-by: Alex Deucher
> ---
> src/mesa/drivers/dri/radeon/radeon_fbo.c | 7 ---
On Wed, Oct 7, 2015 at 12:54 PM, Marek Olšák wrote:
> Ping
>
For the series:
Reviewed-by: Alex Deucher
> On Sat, Oct 3, 2015 at 7:55 PM, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> ---
>> src/gallium/drivers/radeonsi/si_state_draw.c | 6 +++---
>&
On Tue, Jan 12, 2016 at 1:10 PM, Marek Olšák wrote:
> Hi,
>
> For AMD guys: Is it okay with you to push this patch series?
No objections here.
Alex
>
> Thanks,
>
> Marek
>
> On Fri, Jan 8, 2016 at 2:30 AM, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> It will become a system value, not an inp
ample:
> ./autogen.sh --enable-vdpau --disable-opengl --disable-gles1 \
> -disable-gles2 --with-gallium-drivers=radeonsi --with-dri-drivers= \
> --disable-egl --disable-xvmc --disable-dri
>
> Signed-off-by: Jammy Zhou
> Acked-by: Michel Dänzer
> Signed-off-by: Marek Ol
On Thu, Jan 14, 2016 at 10:23 PM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Signed-off-by: Michel Dänzer
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/radeonsi/si_shader.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/gallium/drivers/r
On Fri, Jan 22, 2016 at 10:22 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> It's a subset of ETC2. Tested.
>
> For more information, see page 42 and onward:
> http://www.graphicshardware.org/previous/www_2007/presentations/strom-etc2-gh07.pdf
Reviewed-by: Alex Deucher
On Fri, Jan 22, 2016 at 3:19 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> Set RADEON_ALL_BOS=1 to use it.
Reviewed-by: Alex Deucher
> ---
> src/gallium/winsys/amdgpu/drm/amdgpu_bo.c | 21 +
> src/gallium/winsys/amdgpu/drm/amdgpu_bo.h | 2 ++
>
On Mon, Jan 25, 2016 at 6:35 PM, Nicolai Hähnle wrote:
> On 24.01.2016 16:09, Samuel Pitoiset wrote:
>>
>> Loosely based on tessellation shaders.
>
>
> Do we actually need this? The graphics pipeline and the compute pipeline are
> separate; draw commands should be unaffected by the currently set c
s.
>
> Signed-off-by: Michel Dänzer
For the series:
Reviewed-by: Alex Deucher
> ---
> src/gallium/winsys/amdgpu/drm/amdgpu_bo.c | 19 +--
> 1 file changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
>
On Tue, Feb 2, 2016 at 8:44 AM, Marek Olšák wrote:
> Hi,
>
> The motivation behind this is to allow games that use proprietary extensions
> to query the amount of VRAM to be able to query it with Mesa too. Such games
> are unlikely to use GLX_MESA_query_renderer in the foreseeable feature.
>
> U
201 - 300 of 819 matches
Mail list logo
