List of Video cards in directx.c

[Seth Shelnutt]

On Sat, Jul 10, 2010 at 3:57 PM, Henri Verbeet <hverbeet at gmail.com> wrote:

>
> What kind of issue? (Just curious.)
>
>  Well a 8300 isn't cuda capable, and even with the forcegpu nvidia_g80
flag, wine still makes the client think it's an 8300 not an 8500. So then
fah errors out with:

Initializing Nvidia gpu library
Error setting CUDA device CUDA version is insufficient for CUDART version .


> Maybe. It's not quite as trivial as you make it sound though. You'd
> need a good mechanism to keep the list up-to-date, and note that we
> match against the GL_RENDERER string returned by the OpenGL driver.
> That isn't necessarily the same as the card's product name, and may
> differ between different drivers for the same card. (E.g. Mesa r300
> vs. Mesa r300g vs. fglrx vs. OS X).
>

Looking through the whole directx.c file I see what you mean. I'm not really
sure there is any better way to do it then what it already done. It seems
like it should be made more dynamic so everyone doesn't have to go hardcode
in all the different graphic cards. It seems like instead of having the
driver_version_table hard code everything, why not just add the driver
versions to the existing select_card_nvidia/ati/intel_binary? The
init_driver_info function takes the vender name and the renderer name and
parses the table to get the driver version. To me the table seems like more
work than we need.

What I propose is something like,

        if (case HW_VENDOR_NVIDIA )
        {
           if(strstr(gl_renderer, "card lower than 6100")
                 <insert hardcoded description, video memory and appropriate
drive versions>
         else
            description = ("NVIDIA GeForce  " + gl_renderer);
            driverversiontable[] ={15, 11, 9745};
            if(GL_SUPPORT(NVX_gpu_memory_info))
             {
               glGetIntegerv(0x9048, &vidmen);
                 }

            else
            <use hard coded video memories already available>
        }

That is just quick psuedo code for what I am thinking. The same can be used
for ATI and Intel. The gl_ati_meminfo extension has been around longer than
the Nvidia extension so it should have an even greater presence (since
catalyst 9.2). Anyone who has a 3xxx or newer from ATI or a 4xx from Nvidia
is guaranteed to have the extension for detecting video memory. I know those
are small number but there is also a large user base who has updated
drivers. The old values will have to be hard coded like they are now, and
even new cards will have to be hard coded in case they are not running the
proprietary drivers. However for immediate support having this dynamic
options will work great.

Overall with this, everything will be returned like it is suppose to, and it
is now. There is no lose of functionality and while yes this new code will
be added and a lot of the hard coded values will remain, this at least
provides some level of automatically determining these values and support
for newer cards or cards that have not been hard coded in.

What are your thoughts?


-Seth Shelnutt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20100711/efc4d3cb/attachment-0001.htm>