Re: ..Re AMDGPU Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?

2018-07-31 Thread Chris Cappuccio
> > Ignoring the parts of the shared
> > drm/ttm code that would have to be updated the latest
> > drivers/gpu/drm/amd in linux has over 1.5 million lines of code. Which
> > is multiple times larger than the complete OpenBSD kernel source...
> 

Despite everything you replied with, Jonathan's reply still accurately
details the overriding concern. 

The code base is so huge, not only is porting a herculean task, but who wants
this much code in their kernel to run the...video card?

As a matter of fact, the existing AMD code can be extended to support the newer
hardware without the huge import.

Realistically, neither porting amdgpu nor extending the existing code are going
to happen any time soon. There's no straightforward path to solve this problem.



..Re AMDGPU Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?

2018-07-27 Thread Joseph Mayer
On April 25, 2018 7:08 PM, Jonathan Gray  wrote:
..
> > The Radeon GPU:s are important in OpenBSD's ecosystem as they are the
> > only way to increase graphics functionality, that not involves changing
> > CPU to Intel's latest, and hence change motherboard and other hardware.
> > Do you have plans to port amdgpu?
> > Would particular hardware donations or other donations be of help?
>
> I have no plans regarding amdgpu.
>
> Most people seem to be interested from the point of view of polaris/vega
> which are not supported in linux 4.4. Ignoring the parts of the shared
> drm/ttm code that would have to be updated the latest
> drivers/gpu/drm/amd in linux has over 1.5 million lines of code. Which
> is multiple times larger than the complete OpenBSD kernel source...

Hi Jonathan,

Thank you for your previous response.

I have talked to Alex Deucher (he's on #radeon FreeNode IRC, agd5f) as
well as hwentlan who both work for AMD in depth about the AMDGPU
driver, and they clarify that this is where AMD will give all future
efforts, so from what I understand over time porting AMDGPU will become
more and more relevant and at some point a pushing priority.

>From talking to them, the most important features in AMDGPU appear to
be:

 * GPU scheduler, splits GPU resources between processes
   The GPU scheduler helps load-balance both memory bandwidth and
   rendering work within the GPU between different programs that use 3D
   concurrently, shown on display at same time.

   E.g., say you have two processes submitting work to the GPU. If one
   is submitting work very fast, it's jobs can will get lined up and it
   will monopolize the GPU time if it's first come first server. The
   scheduler makes sure both processes get access to the GPU.

   (No such thing in the old driver)

 * Display handling code (called "DC" in the AMDGPU codebase):
   Lots more display features compared to Radeon: atomic modesetting
   framework on Linux, DP MST, FBC, etc., GPU scheduler, fine grained
   clock and voltage control (similar to wattman in windows), more
   power features supported, etc.

   (DC is the name of the display handling code in AMDGPU.)

 * Fine grained control of the power states (minor tweaks to voltages
   or clocks, etc.)

   (Radeon supported dynamic power management, where the GPU clocks
   could be changed dynamically based on demand, but not fine grained.)

 * Support for MST hubs (so more monitors connected to an MST hub, get
   identified as separate monitors by the computer)

 * 8K monitor support via MST based on 2x displayport connectors

 * DP MST in the old Radeon driver is experimental and doesn't work
   that well, in AMDGPU done well.

 * DRM sync objects support, which enabled a bunch of OGL and EGL
   extensions

 * AMDGPU may get support for freesync/adaptive sync/vrr in the future
   and in the more distant future support for HDR, as in up to 16 bits
   per color.

   hwentlan explains, "for the consumer it means that brights are
   brighter, darks are darker, and you still see tons of details in the
   shadows, even though your screen might show you glare in other
   areas. There are many different HDR formats and ways of tonemapping
   image data into those formats. This requires new interfaces between
   kernel and user-mode, and requires the kernel display driver to
   understand and be able to program the HW to output the required
   formats".

Joseph



Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?

2018-04-30 Thread Patrick Harper
I have a FirePro V5900 (Cayman part from the Northern Islands family) which I 
run with EXA acceleration on 6.2. H264 video with a resolution of 3840x2160 and 
25fps play flawlessly with the OpenGL acceleration in mpv (on a WSXGA+ 
display). Ostensibly this card can drive UHD monitors at their native refresh 
rate that support the MST mode (two virtual panels at 1920x2160), while its 
longer brother, the V7900, can do SST mode.

-- 
  Patrick Harper
  paia...@fastmail.com

On Sat, 28 Apr 2018, at 11:00, Joe Gidi wrote:
> > On Wed, Apr 25, 2018 at 10:49:53AM -0400, Joe Gidi wrote:
> >>
> >> > On Wed, Apr 25, 2018 at 09:08:12PM +1000, Jonathan Gray wrote:
> >> >> drivers/gpu/drm/amd in linux has over 1.5 million lines of code.
> >> Which
> >> >> is multiple times larger than the complete OpenBSD kernel source...
> >>
> >> Thanks for this update!
> >>
> >> Just to clarify, before I spend a bunch of money on new hardware, should
> >> I
> >> be able to use a Radeon R7 250 to drive a 4k monitor via DisplayPort
> >> with
> >> this updated driver?
> >>
> >> Thanks again,
> >
> > It appears that 'R7 250' can mean either a cape verde or oland radeon
> > depending on the model.  Both are GCN parts.
> >
> > 4k 30Hz should be possible with HDMI, 4k 60Hz on HDMI requires HDMI 2.0
> > Both claim support for displayport 1.2 which should be able to do
> > 4k 60Hz.  HDMI 2.0 seems to only be on later hardware with DCE >= 11
> > carrizo (not carrizo-l which is mullins), polaris etc.
> >
> > With the low end radeons displayport is sometimes only available on
> > oem models of cards sold as options for systems marketed as business
> > desktops or workstations.
> >
> > And as mentioned earlier for acceleration you'll currently have to build
> > a different version of Mesa than what OpenBSD releases/snapshots ship
> > with.
> 
> Hi Jonathan,
> 
> Thanks for the detailed answer!
> 
> As best I can tell from wading through the mess of marketing names and
> specifications, accelerated 4k video is currently not an option with
> Radeon cards; the older cards don't support high-enough resolutions, and
> the newer ones don't have acceleration support yet due to the Mesa
> problem. Looks like I might need to buy an Intel machine or wait for the
> Mesa issues to get resolved.
> 
> Thanks again,
> Joe
> 
> 
> -- 
> 
> Joe Gidi
> j...@entropicblur.com
> 
> "You cannot buy skill." -- Ross Seyfried
> 



Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?

2018-04-29 Thread Joe Gidi
> On Wed, Apr 25, 2018 at 10:49:53AM -0400, Joe Gidi wrote:
>>
>> > On Wed, Apr 25, 2018 at 09:08:12PM +1000, Jonathan Gray wrote:
>> >> drivers/gpu/drm/amd in linux has over 1.5 million lines of code.
>> Which
>> >> is multiple times larger than the complete OpenBSD kernel source...
>>
>> Thanks for this update!
>>
>> Just to clarify, before I spend a bunch of money on new hardware, should
>> I
>> be able to use a Radeon R7 250 to drive a 4k monitor via DisplayPort
>> with
>> this updated driver?
>>
>> Thanks again,
>
> It appears that 'R7 250' can mean either a cape verde or oland radeon
> depending on the model.  Both are GCN parts.
>
> 4k 30Hz should be possible with HDMI, 4k 60Hz on HDMI requires HDMI 2.0
> Both claim support for displayport 1.2 which should be able to do
> 4k 60Hz.  HDMI 2.0 seems to only be on later hardware with DCE >= 11
> carrizo (not carrizo-l which is mullins), polaris etc.
>
> With the low end radeons displayport is sometimes only available on
> oem models of cards sold as options for systems marketed as business
> desktops or workstations.
>
> And as mentioned earlier for acceleration you'll currently have to build
> a different version of Mesa than what OpenBSD releases/snapshots ship
> with.

Hi Jonathan,

Thanks for the detailed answer!

As best I can tell from wading through the mess of marketing names and
specifications, accelerated 4k video is currently not an option with
Radeon cards; the older cards don't support high-enough resolutions, and
the newer ones don't have acceleration support yet due to the Mesa
problem. Looks like I might need to buy an Intel machine or wait for the
Mesa issues to get resolved.

Thanks again,
Joe


-- 

Joe Gidi
j...@entropicblur.com

"You cannot buy skill." -- Ross Seyfried



Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?

2018-04-26 Thread bijan

On 04/25/18 17:34, mazocomp wrote:

On Wed, Apr 25, 2018 at 09:08:12PM +1000, Jonathan Gray wrote:

drivers/gpu/drm/amd in linux has over 1.5 million lines of code.  Which
is multiple times larger than the complete OpenBSD kernel source...


Wow, this driver is fatter than elephant.

Anyway, thank you for updating radeondrm(4), now I can
use my PC with Kaveri APU.


Updating to the latest snapshot and the same (good) results.
the HDMI/VGA outputs are detected and changing the brightness is
working on my Lenovo G50-45 (AMD A8-6410 with AMD Radeon R5
Graphics[1]). Thank you :-)

[1]: http://dmesgd.nycbug.org/index.cgi?do=view=3586



Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?

2018-04-26 Thread Jonathan Gray
On Wed, Apr 25, 2018 at 10:49:53AM -0400, Joe Gidi wrote:
> 
> > On Wed, Apr 25, 2018 at 09:08:12PM +1000, Jonathan Gray wrote:
> >> drivers/gpu/drm/amd in linux has over 1.5 million lines of code.  Which
> >> is multiple times larger than the complete OpenBSD kernel source...
> 
> Thanks for this update!
> 
> Just to clarify, before I spend a bunch of money on new hardware, should I
> be able to use a Radeon R7 250 to drive a 4k monitor via DisplayPort with
> this updated driver?
> 
> Thanks again,

It appears that 'R7 250' can mean either a cape verde or oland radeon
depending on the model.  Both are GCN parts.

4k 30Hz should be possible with HDMI, 4k 60Hz on HDMI requires HDMI 2.0
Both claim support for displayport 1.2 which should be able to do
4k 60Hz.  HDMI 2.0 seems to only be on later hardware with DCE >= 11
carrizo (not carrizo-l which is mullins), polaris etc.

With the low end radeons displayport is sometimes only available on
oem models of cards sold as options for systems marketed as business
desktops or workstations.

And as mentioned earlier for acceleration you'll currently have to build
a different version of Mesa than what OpenBSD releases/snapshots ship
with.



Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?

2018-04-25 Thread Patrick Harper
I have a response from an anon poster on the Linux sub on Reddit that may or 
may not be well informed (take it with a pinch of salt), but their posts were 
ostensibly more popular than my queries about amdgpu's mooted bloat, is there 
anyone here who can make sense of their points as to their legitimacy?

>That's nothing. First of all, majority of it is in header files as 
>initialization data and various tables, and the second thing is that  > it's 
>more compartmentalized as compared to radeon (read: there is a lot of 
>duplication).
>
>Memory wise, the cost of the 'bloat' is laughable. And code path wise it's 
>quite comparable to radeon. You don't execute every  > single byte of code 
>just because it's there. You hit some code paths often, some rarely, and some 
>never. Critical paths are the  > ones you want to optimize the hell out of.
>
>Code bloat is a different thing. Usually it refers to layers upon layers of 
>abstraction and crufty interfaces that no longer really  > fit, but are kept 
>for various compatibility/legacy reasons. And even then, it doesn't 
>necessarily translate to performance   > penalties. Usually bloat is 
>something that hits developers rather than users, since large messy codebase 
>is difficult to> maintain.
>
>P.S. There is nothing in modern AMD GPUs that makes them unsupportable by 
>older radeon driver per se, specs are > completely open, 
>nothing prevents you from coming up with your own 'slim' driver. It's just 
>that it has been decided that,   > moving on, new hardware support will be 
>added to amdgpu only. The size of amdgpu results from deliberate architectural 
>> approaches.
>
>First rule of any optimization every dev should know: profile, profile, 
>profile! Without careful measurements you cannot make > proper assessment of 
>performance, even very experienced devs get bit by that when making casual 
>assessments.
>
>If you feel you can trim it down, you're welcome to remove code you deem 
>unnecessary and submit patches to the tree.

Those of us who have a bloaty mainstream browser with Javascript enabled can 
read the whole exchange at 
https://www.reddit.com/r/Amd/comments/7u54d3/lisa_su_we_are_ramping_production_of_gpus/dtkcysq/?context=3

-- 
  Patrick Harper
  paia...@fastmail.com



Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?

2018-04-25 Thread Jeremie Courreges-Anglas
On Wed, Apr 25 2018, Jonathan Gray  wrote:

[...]

> Most people seem to be interested from the point of view of polaris/vega
> which are not supported in linux 4.4.  Ignoring the parts of the shared
> drm/ttm code that would have to be updated the latest
> drivers/gpu/drm/amd in linux has over 1.5 million lines of code.  Which
> is multiple times larger than the complete OpenBSD kernel source...

Made my day...

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?

2018-04-25 Thread mazocomp
On Wed, Apr 25, 2018 at 09:08:12PM +1000, Jonathan Gray wrote:
> drivers/gpu/drm/amd in linux has over 1.5 million lines of code.  Which
> is multiple times larger than the complete OpenBSD kernel source...
> 

Wow, this driver is fatter than elephant.

Anyway, thank you for updating radeondrm(4), now I can
use my PC with Kaveri APU.



Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?

2018-04-25 Thread Jonathan Gray
On Wed, Apr 25, 2018 at 03:10:15AM -0400, Joseph Mayer wrote:
> Hi!
> 
> Radeon drivers are specific per Radeon microarchitecture and Radeon
> microarchitecture version. 
> 
> The Radeon microarchitectures to date are TS 1, TS 2, TS 3, GCN 1, GCN
> 2, GCN 3, GCN 4, GCN 5 (TS = TeraScale and GCN = Graphics Core Next),
> in that ascending chronological order. [1]

Terascale is r600, so there are more than just that.
The drivers in Mesa are radeon (r100), r200, r300, r600, radeonsi.

> 
> 
> First, thank you very much jsg@ for that you committed full OpenBSD
> kernel support for the radeondrm(4) driver today! [2]
> 
> Previously, while Xorg's radeondrm(4) driver supported all cards up to
> GCN 2, OpenBSD's kernel supported the Radeons up to GCN 1 only. The
> radeon(4) man page listed all cards up to GCN 2, but only the cards up
> to GCN 1 were actually supported by OpenBSD.
> 
> jsg@'s diff today extends radeondrm(4) to support Radeons up to GCN 2.

It is worth reiterating that there is no self contained 2d acceleration
in the xorg driver for GCN/radeonsi parts.

Acceleration is only via glamor and requires Mesa to work.
The radeonsi driver in Mesa is not built as it has build time and run
time dependencies on libLLVM and libelf which are not in src or xenocara.
And to use libLLVM from LLVM 6.0 a newer version of Mesa than what is in
the xenocara tree is required (ie 17.3).  Mesa 17.x triggers some kind of
graphical corruption on Intel hardware for reasons still unclear so
xenocara remains on Mesa 13.0.6.

> 
> 
> The major move with Radeon graphics cards today, is their move from the
> radeondrm(4) driver (called "xf86-video-ati" by Xorg and "radeon" on
> Linux) [3], to the "amdgpu" driver (called "xf86-video-amdgpu" by Xorg)
> [4].
> 
> All new Radeon are driven by the amdgpu driver:
> 
> The radeondrm driver supports all Radeon cards up to and including GCN
> 2. GCN 2 was released 2013 and the last GCN 2 card was released 2015.
> No more GCN 2 cards will be coming.

Parts get rebadged through multiple generations of marketing names,
especially on the low end.

> 
> The amdgpu driver supports all new Radeon cards from GCN 1.2 and up.

There are build time options for 'enable experimental support for SI asics'
and 'enable support for CIK asics' which seem to not be the default.

> 
> This means the amdgpu driver is needed for GCN 3 and newer Radeons, and
> GCN 3 cards started coming to the market 2014.
> 
> amdgpu(4) has not been ported to OpenBSD yet. [5]
> 
> 
> I am not perfectly clear about the max feature set in the GCN 2 cards,
> maybe I will make a post later about what you can and cannot do with
> amdgpu(4) (not yet ported) vs. radeondrm(4) cards, however more modern
> features like Displayport 1.4 and 1.3 support, support for higher
> resolutions, MST (Multi-Stream Transport), newer video codecs with
> higher resolutions etc., appear to be only in the newer GCN 5 and GCN 4
> cards, which are supported only by the amdgpu driver.

There are MST parts in radeondrm though they may be experimental.
Many of the GCN parts covered by radeondrm are advertised as being able
to support 4k SST/MST on displayport.

> 
> The Radeon GPU:s are important in OpenBSD's ecosystem as they are the
> only way to increase graphics functionality, that not involves changing
> CPU to Intel's latest, and hence change motherboard and other hardware.
> 
> 
> Do you have plans to port amdgpu?
> 
> Would particular hardware donations or other donations be of help?

I have no plans regarding amdgpu.

Most people seem to be interested from the point of view of polaris/vega
which are not supported in linux 4.4.  Ignoring the parts of the shared
drm/ttm code that would have to be updated the latest
drivers/gpu/drm/amd in linux has over 1.5 million lines of code.  Which
is multiple times larger than the complete OpenBSD kernel source...