An Improved Register Allocator For Gallium3D R300

[phoronix]

Phoronix: An Improved Register Allocator For Gallium3D R300

In recent days I have mentioned many interesting Google Summer of Code project that have been proposed for this year: WebM VDPAU state tracker, better multi-GPU support, the OpenCL state tracker, and even a Direct3D HLSL shader compiler. It will be interesting to see which of these projects actually materialize since the success rate of GSoC projects aren't incredibly high, especially if counting the ones that end up succeeding but never end up being maintained after the summer or the code is never merged. Fortunately, one of last year's GSoC Mesa projects is still being hacked on and there's more to report on it today...

http://www.phoronix.com/vr.php?view=OTI2Ng

[cb88]

I'd appreciate it at least if you ran it on some of the older ones as well the radeon 9800 for instance (While I have a 9800 SE which is weaker its still in the same class) ... I mean if you only run it on fast cards we won't know if it improves fast cards more or slow cards. Higher end cards have more to work with so i expect slower cards may see more improvment myself.

[Michael]

I'd appreciate it at least if you ran it on some of the older ones as well the radeon 9800 for instance (While I have a 9800 SE which is weaker its still in the same class) ... I mean if you only run it on fast cards we won't know if it improves fast cards more or slow cards. Higher end cards have more to work with so i expect slower cards may see more improvment myself.

Oldest card I have is an X800XL and even that is rather vintage for my interests. I tried using that this morning though for these tests but it doesn't like some new motherboards, including the Intel Sandy Bridge system I am using for this testing. So this initial register allocation testing is with an X1300PRO and HD 1950PRO I think.

[Veerappan]

Oldest card I have is an X800XL and even that is rather vintage for my interests. I tried using that this morning though for these tests but it doesn't like some new motherboards, including the Intel Sandy Bridge system I am using for this testing. So this initial register allocation testing is with an X1300PRO and HD 1950PRO I think.

Sounds like a good starting range to me. X1300 should be slower than a 9800 Pro anyway, although the x1300 and 1950 are both from the same generation, so the architecture should be similar between the two cards. It would give me a semi-relevant performance estimate for the x300 mobile in my old Inspiron laptop as well.

[Michael]

Sounds like a good starting range to me. X1300 should be slower than a 9800 Pro anyway, although the x1300 and 1950 are both from the same generation, so the architecture should be similar between the two cards. It would give me a semi-relevant performance estimate for the x300 mobile in my old Inspiron laptop as well.

Turns out the X1300PRO won't boot with the Sandy Bridge motherboard either, so I'm just stuck with an X1800XL and X1950PRO...

[cb88]

Meh.. I understand. I'd run the test but my box is severely CPU limited 2x300Mhz and buss limited AGP 2x

[Veerappan]

Do you still have any old laptops laying around with a built-in radeon of that generation? It won't be perfect, as you'd have a CPU-speed difference between the sandy bridge and laptop system, but you could still give relative improvements between versions of the software stack within given a piece of hardware.

[Michael]

Do you still have any old laptops laying around with a built-in radeon of that generation? It won't be perfect, as you'd have a CPU-speed difference between the sandy bridge and laptop system, but you could still give relative improvements between versions of the software stack within given a piece of hardware.

Yes, but haven't decided if that'd be worthwhile yet depending upon popularity of X1800XL/X1950PRO results.

[Veerappan]

Yes, but haven't decided if that'd be worthwhile yet depending upon popularity of X1800XL/X1950PRO results.

Fair enough. It's not like I can't run the tests myself if I really want to know how the low-end hardware runs.

[oibaf]

Isn't GL_ARB_color_buffer_float patented? From http://www.opengl.org/registry/specs...ffer_float.txt :

IP Status

SGI owns US Patent #6,650,327, issued November 18, 2003. SGI
believes this patent contains necessary IP for graphics systems
implementing floating point (FP) rasterization and FP framebuffer
capabilities.

SGI will not grant the ARB royalty-free use of this IP for use in
OpenGL, but will discuss licensing on RAND terms, on an individual
basis with companies wishing to use this IP in the context of
conformant OpenGL implementations. SGI does not plan to make any
special exemption for open source implementations.

Contact Doug Crisman at SGI Legal for the complete IP disclosure.

which is the same of GL_ARB_texture_float http://www.opengl.org/registry/specs...ture_float.txt that it's still in the floating2 branch.