On 11/30/2015 02:06 PM, Dave Airlie wrote:
> On 1 December 2015 at 07:18, Emil Velikov <emil.l.veli...@gmail.com> wrote:
>> On 30 November 2015 at 20:00, Ian Romanick <i...@freedesktop.org> wrote:
>>> On 11/29/2015 07:21 AM, Emil Velikov wrote:
>>>> Hi Giuseppe,
>>>>
>>>> On 28 November 2015 at 15:43, Giuseppe Bilotta
>>>> <giuseppe.bilo...@gmail.com> wrote:
>>>>> The second and third patches are mostly aimed at removing non-spurious
>>>>> compiler warnings. The first one is just minor whitespace cleanup in the
>>>>> general area of code touched by the second patch.
>>>>>
>>>>> Giuseppe Bilotta (3):
>>>>> radeon: whitespace cleanup
>>>>> radeon: const correctness
>>>>> xvmc: force assertion in XvMC tests
>>>>>
>>>> With the small comment in patch 3 addressed the series is
>>>> Reviewed-by: Emil Velikov <emil.l.veli...@gmail.com>
>>>>
>>>> If you're looking for an easy task - there is one in radeon/r200.
>>>> Currently we have a lot of nasty in-tree symlinks, symbol duplication
>>>> and hacks to get around it. Let me know if you'd like more info/tips
>>>> on how to tackle it.
>>>
>>> This is something that has been annoying me a bit lately. What do you
>>> think the right solution is? The Intel driver used to have a common
>>> src/mesa/drivers/dri/intel directory that was compiled once and shared
>>> by i915 and i965. The code paths started to diverge quite a lot, so we
>>> copied the shared files into each directory... and became non-shared.
>>> Note that we didn't rename any of the function names, so we still have
>>> the ugly hacks to get around the symbol duplication.
>>>
>> I'm not sure about "right and wrong" but the possible solution I was
>> thinking is the one you mentioned - have a common place where that
>> code is built once.
>>
>> The long version:
>> 1. Grep for RADEON_R{1,2}00 and look at the guarded code
>> 1.1 Some guards can just be dropped (CHIP_FAMILY_*, get_chip_family_name),
>> 1.2 Other hunks of code can be split/moved into the respective
>> r100/r200 codebase (radeonTexBufferExtension and
>> r200TexBufferExtension).
>> 1.3 Or folded into the vtbl dispatch - get_depth_z32/16 or the
>> respective callers, depending on the overhead (neither one is likely
>> to be noticeable).
>> 2. Copy/pasta an existing radeon Makefile to radeon_common. Tweak to
>> produce an empty library and get it into the final mega_dri_drivers.so
>> 2.1 With most/all of the RADEON_R*00 guards gone, one should be able
>> to just git mv the files into the new location. (alongside dropping
>> the symlinks)
>> 2.2 Remove the symbol redefinition hack.
>>
>> It's a lengthy task, yet relatively easy. As long one tries to divide
>> and concur, rather than understand, in depth, how the driver/autohell
>> buildsystem works :-)
>> I'm more than willing to help out on the lot (esp. the latter), just
>> shout when you get confused/stuck.
>
> But why bother?
>
> Getting someone with r100/r200 hardware to test is the fun part,
>
> We've already seen that changes in this area untested mostly break stuff,
> rather than help, and go unnoticed for whole releases at a time.
I'm putting together some systems to run piglit from time to time. If
someone is willing to do some work, I can run tests... but I agree that
this is pretty low priority stuff.
> Dave.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
