Updated and Optimized Ubuntu Free Graphics Drivers

[SystemCrasher]

I think that's just the string of version which was compiled and it's not meaningful, I just forced a rebuild with newer llvm of mesa and libclc anyway.

Well, looking on behavior I got impression it is really updated lib. Yet it presents itself as -rc1 in generated code. That's what puzzled me a bit.

As for bugs... as you can see, I've been running some internal checks. And I can admit LLVM 3.6 is first version which can cope with some OpenCL loads without crashing whole GPU (often means loss of graphics in whole system) or at least calling program. While there're some odds, most of them are already known to AMD devs as far as I know.

[groo_pcd]

Well, looking on behavior I got impression it is really updated lib. Yet it presents itself as -rc1 in generated code. That's what puzzled me a bit.

As for bugs... as you can see, I've been running some internal checks. And I can admit LLVM 3.6 is first version which can cope with some OpenCL loads without crashing whole GPU (often means loss of graphics in whole system) or at least calling program. While there're some odds, most of them are already known to AMD devs as far as I know.

If you want you can test my PPA, which has latest llvm 3.7git with latest mesa, intel, etc AND opencl (i386/amd64) with amdgcn enabled for radeonsi.

https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa/

opencl looks to be working too:

16:21 Seg Fev 02$ ./cl-demo 1000000 10
Choose platform:
[0] Mesa
Enter choice: 0
Choose device:
[0] AMD CAPE VERDE
Enter choice: 0
---------------------------------------------------------------------
NAME: AMD CAPE VERDE
VENDOR: X.Org
PROFILE: FULL_PROFILE
VERSION: OpenCL 1.1 MESA 10.5.0-devel (padoka PPA)
EXTENSIONS:
DRIVER_VERSION: 10.5.0-devel (padoka PPA)

Type: GPU
EXECUTION_CAPABILITIES: Kernel
GLOBAL_MEM_CACHE_TYPE: None (0)
CL_DEVICE_LOCAL_MEM_TYPE: Local (1)
SINGLE_FP_CONFIG: 0x7
QUEUE_PROPERTIES: 0x2

VENDOR_ID: 4098
MAX_COMPUTE_UNITS: 10
MAX_WORK_ITEM_DIMENSIONS: 3
MAX_WORK_GROUP_SIZE: 256
PREFERRED_VECTOR_WIDTH_CHAR: 16
PREFERRED_VECTOR_WIDTH_SHORT: 8
PREFERRED_VECTOR_WIDTH_INT: 4
PREFERRED_VECTOR_WIDTH_LONG: 2
PREFERRED_VECTOR_WIDTH_FLOAT: 4
PREFERRED_VECTOR_WIDTH_DOUBLE: 2
MAX_CLOCK_FREQUENCY: 625
ADDRESS_BITS: 32
MAX_MEM_ALLOC_SIZE: 268435456
IMAGE_SUPPORT: 0
MAX_READ_IMAGE_ARGS: 32
MAX_WRITE_IMAGE_ARGS: 32
IMAGE2D_MAX_WIDTH: 32768
IMAGE2D_MAX_HEIGHT: 32768
IMAGE3D_MAX_WIDTH: 4096
IMAGE3D_MAX_HEIGHT: 4096
IMAGE3D_MAX_DEPTH: 4096
MAX_SAMPLERS: 0
MAX_PARAMETER_SIZE: 1024
MEM_BASE_ADDR_ALIGN: 128
MIN_DATA_TYPE_ALIGN_SIZE: 128
GLOBAL_MEM_CACHELINE_SIZE: 0
GLOBAL_MEM_CACHE_SIZE: 0
GLOBAL_MEM_SIZE: 1073741824
MAX_CONSTANT_BUFFER_SIZE: 268435456
MAX_CONSTANT_ARGS: 0
LOCAL_MEM_SIZE: 32768
ERROR_CORRECTION_SUPPORT: 0
PROFILING_TIMER_RESOLUTION: 0
ENDIAN_LITTLE: 1
AVAILABLE: 1
COMPILER_AVAILABLE: 1
MAX_WORK_GROUP_SIZES: 256 256 256
---------------------------------------------------------------------
*** Kernel compilation resulted in non-empty log message.
*** Set environment variable CL_HELPER_PRINT_COMPILER_OUTPUT=1 to see more.
*** NOTE: this may include compiler warnings and other important messages
*** about your code.
*** Set CL_HELPER_NO_COMPILER_OUTPUT_NAG=1 to disable this message.
0.000870 s
27.597392 GB/s
GOOD

and

16:21 Seg Fev 02$ clinfo
Number of platforms: 1
Platform Profile: FULL_PROFILE
Platform Version: OpenCL 1.1 MESA 10.5.0-devel (padoka PPA)
Platform Name: Clover
Platform Vendor: Mesa
Platform Extensions: cl_khr_icd


Platform Name: Clover
Number of devices: 1
Device Type: CL_DEVICE_TYPE_GPU
Device ID: 4098
Max compute units: 10
Max work items dimensions: 3
Max work items[0]: 256
Max work items[1]: 256
Max work items[2]: 256
Max work group size: 256
Preferred vector width char: 16
Preferred vector width short: 8
Preferred vector width int: 4
Preferred vector width long: 2
Preferred vector width float: 4
Preferred vector width double: 2
Native vector width char: 16
Native vector width short: 8
Native vector width int: 4
Native vector width long: 2
Native vector width float: 4
Native vector width double: 2
Max clock frequency: 625Mhz
Address bits: 32
Max memory allocation: 268435456
Image support: No
Max number of images read arguments: 32
Max number of images write arguments: 32
Max image 2D width: 5
Max image 2D height: 0
Max image 3D width: 16884632
Max image 3D height: 139724036292136
Max image 3D depth: 140737199208032
Max samplers within kernel: 0
Max size of kernel argument: 1024
Alignment (bits) of base address: 128
Minimum alignment (bytes) for any datatype: 128
Single precision floating point capability
Denorms: Yes
Quiet NaNs: Yes
Round to nearest even: Yes
Round to zero: No
Round to +ve and infinity: No
IEEE754-2008 fused multiply-add: No
Cache type: None
Cache line size: 0
Cache size: 0
Global memory size: 1073741824
Constant buffer size: 268435456
Max number of constant args: 0
Local memory type: Local
Local memory size: 32768
Error correction support: 0
Unified memory for Host and Device: 1
Profiling timer resolution: 0
Device endianess: Little
Available: Yes
Compiler available: Yes
Execution capabilities:
Execute OpenCL kernels: Yes
Execute native function: No
Queue properties:
Out-of-Order: No
Profiling : Yes
Platform ID: 0x7f1408dd4ae0
Name: AMD CAPE VERDE
Vendor: X.Org
Device OpenCL C version: OpenCL C 1.1
Driver version: 10.5.0-devel (padoka PPA)
Profile: FULL_PROFILE
Version: OpenCL 1.1 MESA 10.5.0-devel (padoka PPA)

enjoy!

[SystemCrasher]

If you want you can test my PPA, which has latest llvm 3.7git with latest mesa, intel, etc AND opencl (i386/amd64) with amdgcn enabled for radeonsi.

Well, I'm quite positive about that in general, because since most things are done in GPU side as shaders, compiler happens to be thing of paramount importance. And old LLVM versions were just awful and even recent versions are far from being good quality & feature-complete.

Though...
1) I don't have Intel GPUs capable of OpenCL. I have some older intel integrated GPUs but Intel seems to mostly ignore these. Even OpenGL support on these is quite limited. So TBH I do not see major reasons to uplift graphic stack on such systems. I can't expect much from these and it not likely to change as Intel seems to disregard older hardware almost completely.

2) I have some systems running VLIW based and GCN based GPUs and I'm interested in OpenCL for sure. Yet, I currently use Ubuntu 14.04 on most of these. I have uplifted most of graphics stack from Oibaf PPA and also updated kernels (something roughly equivalent to 3.19RC6) as it takes minimal efforts on my side and causes minimal dusturbance and easy to undo. But your PPA only seems to exist for Ubuntu 14.10. Upgrading to 14.10 is a part of plan for sure, but it requires to spent some time on this and I haven't done it yet on most systems (since I have more or less recent graphics and kernel, it is not as pressing as it could be).

(on side note, your PPA is one of reasons why I may want to upgrade to 14.10, Phoronix already PRed it couple of times, so I noticed it too )

[Guest]

Just checking, but are the mesa packages on both the oibaf PPA and the gallium-nine dev PPA from git? And do they both receive the same fixes/changes from git? And if so, is the only real difference between the two mesa packages is that the gallium-nine one also gets fixes/changes for... gallium-nine-related stuff?

[Guest]

And an additional question (didn't make it in-time for the edit period); could the gallium-nine mesa be used with Paulo's PPA? The main concern is; does Mesa have to be built with a specific LLVM package in-mind?

[sarnex]

Just checking, but are the mesa packages on both the oibaf PPA and the gallium-nine dev PPA from git? And do they both receive the same fixes/changes from git? And if so, is the only real difference between the two mesa packages is that the gallium-nine one also gets fixes/changes for... gallium-nine-related stuff?

The graphics-drivers ppa follows the gallium nine in Mesa Git. The gallium-nine PPA follows ixit/Mesa-3D which isn't rebased against Mesa Git too often. The former has less Nine changes since the Ixit repo has changes not submitted to the ML/waiting approval. About the second point, no idea.

[Guest]

Has the way DRI_PRIME works changed by some chance? On my A+A muxless laptop, Ubuntu's gpu-manager only sees one GPU, and using DRI_PRIME=1 glxinfo only shows the renderer on the iGPU (expected the dGPU).

Xorg.0.log shows the dGPU loading though, and playing back a movie with mpv on the dGPU has "somewhat expected" results (video doesn't show; crashes X when maximized; DRI_PRIME=0 is fine though). xrandr --listproviders shows 2 (3; one source is repeated) sources.

So basically, DRI_PRIME doesn't show my dGPU when polling for info, but it does seem to be used regardless.

I'm using Ubuntu 14.10 and the DRI3 test PPA if it matters. Results are the same when using either Paulo's or oibaf's PPA.

[asdfblah]

Has the way DRI_PRIME works changed by some chance? On my A+A muxless laptop, Ubuntu's gpu-manager only sees one GPU, and using DRI_PRIME=1 glxinfo only shows the renderer on the iGPU (expected the dGPU).

Xorg.0.log shows the dGPU loading though, and playing back a movie with mpv on the dGPU has "somewhat expected" results (video doesn't show; crashes X when maximized; DRI_PRIME=0 is fine though). xrandr --listproviders shows 2 (3; one source is repeated) sources.

So basically, DRI_PRIME doesn't show my dGPU when polling for info, but it does seem to be used regardless.

I'm using Ubuntu 14.10 and the DRI3 test PPA if it matters. Results are the same when using either Paulo's or oibaf's PPA.

Try restarting the X server manually (sudo service lightdm/kdm/... restart) and running the commands again...

[commiethebeastie]

And an additional question (didn't make it in-time for the edit period); could the gallium-nine mesa be used with Paulo's PPA? The main concern is; does Mesa have to be built with a specific LLVM package in-mind?

Yes, for using sarnex wine you must create symlinks:

ln -s /usr/lib/i386-linux-gnu/mesa /usr/lib/i386-linux-gnu/d3d

ln -s /usr/lib/x86_64-linux-gnu/mesa /usr/lib/x86_64-linux-gnu/d3d

[Guest]

Yes, for using sarnex wine you must create symlinks:

ln -s /usr/lib/i386-linux-gnu/mesa /usr/lib/i386-linux-gnu/d3d

ln -s /usr/lib/x86_64-linux-gnu/mesa /usr/lib/x86_64-linux-gnu/d3d

I meant the PPA, not gallium-nine (found out the symlink a little while back)

To be clear, I wanted to see if I could use Paulo's PPA, with oibaf's gallium-nine PPA. It would seem LLVM 3.7 is not installed with the gallium-nine PPA, so it seems Mesa does depends on a specific build of LLVM.