[PATCH] Merging Render code into r128_exa.c

Alex Deucher alexdeucher at gmail.com
Fri Aug 26 13:52:38 UTC 2016

On Fri, Aug 26, 2016 at 2:21 AM, Connor Behan <connor.behan at gmail.com> wrote:
> On 25/08/16 11:40 PM, Kevin Brace wrote:
>> Hi Connor,
>> I do not mean to harass you regarding this patch or my response to your feedback, but it will be nice if you can reply to my response I sent to the mailing list regarding what to do with the Render code.
>> I did modify the original proposal, and maintains a separate r128_exa_render.c file, but will like to get rid of that #include in the middle of the code inside r128_exa.c. (I am happy with this second proposal if you wanted to adopt it.)
>> I will like to eventually work on fixing the EXA rendering bug that still exists, but prior to that, I was trying to test the waters before jumping into it.
>> I do have one AGP-based system (HP Pavilion a800n; AMD Athlon XP + VIA Technologies KM400A chipset) with RAGE 128 Pro AGP 32 MB with TV out I can use for r128 DDX development, and I have managed to compile drm-openchrome for Lubuntu 14.04 LTS. (It can boot RAGE 128 Pro fine, but not with OpenChrome for now due to its KMS bug in the drm-openchrome).
>> Of course, I still see the rendering bugs, and I will like to fix it for people who still care about it.
>> Regards,
>> Kevin Brace
> I don't feel strongly that the patch is needed or that it is not needed
> since both proposals are cosmetic. So if you go ahead and apply the one
> you like, I'm certainly not going to revert it. However, to fix the bugs
> you're talking about, I can almost guarantee that the functions you'll
> need to hack are in r128_exa_render.c and not r128_exa.c. So in that
> sense it helps to have separate files. Any contributions you have
> planned would be welcome. Especially since I had too many things come up
> over the last year that regrettably took me away from r128 development.

For some historical background, the render acceleration generally used
the 3D engine while the regular exa code used the 2D engine.
Additionally, some of the older chips implemented support for both
MMIO and DMA based acceleration so there were sets of macros to
support both and the code was compiled twice, once for MMIO and once
for DMA.  I don't remember off hand if r128 supported both MMIO and
DMA or not.


More information about the xorg-driver-ati mailing list