AMD Catalyst 9.10 dropped in Ubuntu 9.10

Quote:

---

Originally Posted by bridgman

I couldn't find a bugzilla ticket for the "washed out colours". I didn't go through every single ticket with "Xv" but I did go through all the ones with likely sounding descriptions (and more). Can someone file a ticket with an example, preferably with a link to the (legal) video file ?

I know we went through a *lot* of discussion regarding the open source drivers and what was actually "correct" - the specs are kind of vague about when each conversion matrix should be used so the devs tried a series of different heuristics until everyone seemed happy with the results.

There doesn't seem to be a clear "right and wrong" here, just a variety of opinions. IIRC part of the problem is that video files are not tagged to identify which conversion matrix was used for encoding, so the driver has to guess based on things like video resolution (eg SD is usually encoded one way, HD is usually encoded another way).

---

I never filed a bug because for me it's SO OBVIOUS that I assumed everybody knew and nobody cared / knew how to solve it. For example, I find it impossible to find a #000000 colored pixel with fglrx + xv. The lowest color I can find is a greyish #101010. Just play a video with a black start and notice the difference between the bands and the image:

http://www.xente.mundo-r.com/narf/img/screens/xv.png

With fglrx + gl, fglrx + x11 or EVERY other video driver (radeon, nouveau, nvidia and intel, I also have intel and nvidia chips) it looks like this:

http://www.xente.mundo-r.com/narf/img/screens/gl.png

The same happens with whites or other strong colors. And it has been like this since I bought my 3850... 21 months ago.

Well it is a vsync error - which is extra funny when it looks much better with xv and oss driver...

That's not a fglrx specific bug it happens with Windows too. ATI always uses Video-Level for Videos and there ist no way to configure it to PC-Level.

I'll ask around; it's possible we're using playback on Windows as a reference.

I also suffer from the washed out colours, exactly as Fran describes it.

For reference, I just did a comparison on a trailer for Diablo 3 which I downloaded earlier today. (Monk Trailer). In one window I had Totem running Xv. In another window I had smplayer running OpenGL. Both players where running side by side and in sync. OpenGL yeilds much better result. Xv was gray by comparison. Tough the trailer doesn't contain much colour it's still possible to notice the washed out colours.

I'm running Catalyst 9.8 and Ubuntu 9.04.

Quote:

---

Originally Posted by Silverthorn

I also suffer from the washed out colours, exactly as Fran describes it.

---

I'm pretty sure everybody does; as Muad'Dib pointed out this is most probably caused by fglrx using 16-235 instead of 0-255 for each RGB component under xv.

I seem to remember there was a registry trick to solve the problem in windows (force the driver to expand to 0-255), but in linux... :rolleyes:

Great to see people talking about this issue :)
Frans screenshots nails it. It's funny that with free radeon driver when using Xv the black is black like it should be, but for some reason just like it shows that with catalyst it's brown in a way like some early LCD screens produced black back in the days.

Thanks AMD for the driver, don't forget to release 9.9 and 9.10 (final), too :p

Quote:

---

Originally Posted by d2kx

But the 1-2s freezes when maximizing windows/etc. are still there.

---

of course it's still there !

you haven't re-compiled your x-server with the fix from fedora (it's an issue caused by intel from what I've read so far);)

fglrx+kde4+composite, how to make it really fast (f.g.o)

the patch is called: fedora_dont_backfill_bg_none.patch patch

when using an x-server with that patch included there's no delay in maximizing (none with compiz and none with kwin's opengl backend) :D

For the slow resize fiasco, the solution for distros is simple:

1. Keep the backfill functionality in the default x server packages.
2. Add the no backfill x server package to the repository
3. Modify fglrx package building script to set the x server no backfill package as a recommended or dependency.
4. When users install the driver, the good x server will also be pulled.


Why is this not done?:eek:

anyone tried KDE4 kwin's compositing with opengl and whether the invert effect works now ?

since I switched from nvidia at the beginning of this year it never worked for me with fglrx even though fglrx seems to support the needed extensions for the effects to work

Quote:

---

Originally Posted by Zarin

The invert effect requires fragment shaders to work. Please copy/paste the output of the following:

Code:

---

glxinfo | grep -iE '(shad)|(string)'

---

If you cannot see GL_ARB_fragment_shader and GL_ARB_shading_language_100 then your system doesn't support the required functionality.

---

the output I got was:

Quote:

---

glxinfo | grep -iE '(GL_ARB_fragment_shader)|(GL_ARB_shading_language _100)|(string)|shad'
server glx vendor string: ATI
server glx version string: 1.4
client glx vendor string: ATI
client glx version string: 1.4
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Radeon HD 4800 Series
OpenGL version string: 2.1.8870
OpenGL shading language version string: 1.40
GL_AMDX_vertex_shader_tessellator, GL_AMD_draw_buffers_blend,
GL_AMD_vertex_shader_tessellator, GL_ARB_color_buffer_float,
GL_ARB_fragment_program_shadow, GL_ARB_fragment_shader,
GL_ARB_geometry_shader4, GL_ARB_half_float_pixel,
GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shader_objects,
GL_ARB_shader_texture_lod, GL_ARB_shading_language_100, GL_ARB_shadow,
GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp,
GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_vertex_shader,
GL_ATI_fragment_shader, GL_ATI_meminfo, GL_ATI_separate_stencil,
GL_EXT_geometry_shader4, GL_EXT_gpu_program_parameters,
GL_EXT_gpu_shader4, GL_EXT_multi_draw_arrays, GL_EXT_packed_depth_stencil,
GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, GL_EXT_subtexture,

---

some more info on this issue:
http://forum.kde.org/viewtopic.php?f=111&t=63748

@bridgman:
could you please take a look at it ?
it more seems kind of an driver-problem of fglrx than a problem of kwin itself

many thanks in advance