On Fri, Dec 9, 2016 at 9:34 PM, Dave Airlie airl...@gmail.com> wrote:
> On 10 December 2016 at 05:59, Daniel Vetter wrote:
>> I guess things went a bit sideways by me and Dave only talking about
>> the midlayer, so let me first state that the DC stuff has massively
>> improved through replacing al
I think that pinned VRAM memory (memory that's reserved for kernel use
only) is subtracted from the total VRAM size.
amdgpu DRM 3.9.0 has a new query that returns both the total physical
and total usable VRAM, but Mesa doesn't use it.
Marek
On Sat, Dec 10, 2016 at 11:31 PM, Kai Wasserbäch
wrote
On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote:
> We propose to use the Display Core (DC) driver for display support on
> AMD's upcoming GPU (referred to by uGPU in the rest of the doc). In order to
> avoid a flag day the plan is to only support uGPU initially and transition
> to ol
On 8 December 2016 at 12:02, Harry Wentland wrote:
> We propose to use the Display Core (DC) driver for display support on
> AMD's upcoming GPU (referred to by uGPU in the rest of the doc). In order to
> avoid a flag day the plan is to only support uGPU initially and transition
> to older ASICs gr
Thanks Dave. Apologies in advance for top posting but I'm stuck on a mail
client that makes a big mess when I try...
>If DC was ready for the next-gen GPU it would be ready for the current
>GPU, it's not the specific ASIC code that is the problem, it's the
>huge midlayer sitting in the middle.
couple of typo fixes re: top posting and "only supports" -> "is only used for"
From: Bridgman, John
Sent: December 11, 2016 10:21 PM
To: Dave Airlie; Wentland, Harry
Cc: dri-devel; amd-gfx mailing list; Deucher, Alexander; Lazare, Jordan; Cheng,
Tony; Cyr, Aric;
v3 with typo fixes and additional comments/questions..
From: Bridgman, John
Sent: December 11, 2016 10:21 PM
To: Dave Airlie; Wentland, Harry
Cc: dri-devel; amd-gfx mailing list; Deucher, Alexander; Lazare, Jordan; Cheng,
Tony; Cyr, Aric; Grodzovsky, Andrey
Subje
>
>>This code needs rewriting, not cleaning, not polishing, it needs to be
>>split into its constituent parts, and reintegrated in a form more
>>Linux process friendly.
>
>
> Can we say "restructuring" just for consistency with Daniel's message (the
> HW-dependent bits don't need to be rewritten bu
Yep, good point. We have tended to stay a bit behind bleeding edge because our
primary tasks so far have been:
1. Support enterprise distros (with old kernels) via the hybrid driver
(AMDGPU-PRO), where the closer to upstream we get the more of a gap we have to
paper over with KCL code
2. Pus
