Announcement

Collapse
No announcement yet.

HOWTO implement an OpenGL extension for Mesa

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by netkas View Post
    btw. those can be fixed easily, cuz seems to be static values, depending on card family, just need to find exact value and add them

    EE r600_screen.c/r600_get_param:110 - r600: unknown param 43 - PIPE_CAP_MAX_FS_INSTRUCTIONS
    ......
    EE r600_screen.c/r600_get_param:110 - r600: unknown param 64 - PIPE_CAP_DEPTH_CLAMP
    a patch for most of these issues, based on data from r600c and a bit on data from r300g

    http://mirror.netkas.org/patch_r600g.diff

    Code:
    --- mesa/src/gallium/drivers/r600/r600_screen.c	2010-08-06 18:26:20.000000000 +0400
    +++ mesa/src/gallium/drivers/r600/r600_screen.c	2010-08-08 23:13:29.000000000 +0400
    @@ -52,6 +52,9 @@
     
     static int r600_get_param(struct pipe_screen* pscreen, enum pipe_cap param)
     {
    +struct r600_screen *screen = r600_screen(pscreen);
    +enum radeon_family family = radeon_get_family(screen->rw);
    +
     	switch (param) {
     	case PIPE_CAP_MAX_TEXTURE_IMAGE_UNITS:
     	case PIPE_CAP_MAX_COMBINED_SAMPLERS:
    @@ -106,6 +109,40 @@
     	case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT:
     	case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER:
     		return 0;
    +	case PIPE_CAP_MAX_FS_INSTRUCTIONS:
    +	case PIPE_CAP_MAX_FS_ALU_INSTRUCTIONS:
    +		return 8192;
    +	case PIPE_CAP_MAX_FS_TEX_INSTRUCTIONS:
    +		if (family >= CHIP_R600 && family < CHIP_RV770)
    +		    return 8;
    +		else
    +		    return 16;
    +	case PIPE_CAP_MAX_FS_TEX_INDIRECTIONS:
    +		return 8; /* ??? */
    +	case PIPE_CAP_MAX_FS_INPUTS:
    +		return 32;
    +	case PIPE_CAP_MAX_FS_TEMPS:
    +		return 128;
    +	case PIPE_CAP_MAX_FS_ADDRS:
    +		return 0;
    +	case PIPE_CAP_MAX_FS_CONSTS:
    +		return 0;
    +	case PIPE_CAP_MAX_VS_INSTRUCTIONS:
    +	case PIPE_CAP_MAX_VS_ALU_INSTRUCTIONS:
    +		return 8192;
    +	case PIPE_CAP_MAX_VS_TEX_INSTRUCTIONS:
    +	case PIPE_CAP_MAX_VS_TEX_INDIRECTIONS:
    +		return 0;
    +	case PIPE_CAP_MAX_VS_INPUTS:
    +		return 160;
    +	case PIPE_CAP_MAX_VS_TEMPS:
    +		return 128;
    +	case PIPE_CAP_MAX_VS_ADDRS:
    +		return 1;
    +	case PIPE_CAP_MAX_VS_CONSTS:
    +		return 256;
    +	case PIPE_CAP_GEOMETRY_SHADER4:
    +		return 0;
     	default:
     		R600_ERR("r600: unknown param %d\n", param);
     		return 0;

    Comment


    • #17
      There's also not much point in spending much effort on the classic drivers, and focus on Gallium3D instead, or am I wrong?

      Comment


      • #18
        Originally posted by netkas View Post
        a patch for most of these issues, based on data from r600c and a bit on data from r300g

        http://mirror.netkas.org/patch_r600g.diff
        A lot of those numbers are little off, I need to extract the real numbers from docs, or someone else might do.

        Comment


        • #19
          Originally posted by whizse View Post
          There's also not much point in spending much effort on the classic drivers, and focus on Gallium3D instead, or am I wrong?
          That's what VMWare/TG, Nouveau, and Radeon people think. However Intel doesn't seem to be moving to Gallium anytime soon.

          Comment


          • #20
            Originally posted by marek View Post
            A lot of those numbers are little off, I need to extract the real numbers from docs, or someone else might do.
            well, i tried to look at docs, r600isa.pdf, 3d programming pdf and registers pdf, and didnt find anything usefull

            Comment


            • #21
              Originally posted by marek View Post
              That's what VMWare/TG, Nouveau, and Radeon people think. However Intel doesn't seem to be moving to Gallium anytime soon.
              Yeah, I was thinking mostly about Radeon here.

              Comment


              • #22
                Posting here again, all Hopes on Marek

                a little patch to add card's model names to r600g

                so now it displays card model in glxinfo for me

                OpenGL vendor string: X.Org
                OpenGL renderer string: Gallium 0.4 on ATI Radeon HD 4850
                OpenGL version string: 2.1 Mesa 7.9-devel
                OpenGL shading language version string: 1.20

                currently there is ~65 model names

                http://mirror.netkas.org/r600g/r600g_names.diff

                Comment


                • #23
                  Let not do that. Something like what the classic drivers or r300g do would be better.

                  Comment


                  • #24
                    Originally posted by agd5f View Post
                    Let not do that. Something like what the classic drivers or r300g do would be better.
                    care to explain why ?

                    Comment


                    • #25
                      We really only need to expose the asic variant (rs780, rv620, rv730, etc.) the "full" names are just marketing names and tend to confuse users and cause bug reports. E.g., my "Radeon HD 4370 Ultra Extreme Edition Super++ is incorrectly reported as a Radeon HD 4550", etc.

                      Comment


                      • #26
                        Originally posted by agd5f View Post
                        We really only need to expose the asic variant (rs780, rv620, rv730, etc.) the "full" names are just marketing names and tend to confuse users and cause bug reports. E.g., my "Radeon HD 4370 Ultra Extreme Edition Super++ is incorrectly reported as a Radeon HD 4550", etc.
                        you are right, i thought about same.

                        Comment


                        • #27
                          Part of the problem is that you will often find multiple names mapped to the same IDs.

                          This normally leads to a never-ending series of "fix the name" patches each "correcting the problem introduced by the previous patch"

                          Comment


                          • #28
                            but, can't you just ignore such "bug"-reports ?

                            Comment


                            • #29
                              The issue is that if the naming is more detailed than the ID/name mapping will support the results are actually *worse* for most users

                              Comment


                              • #30
                                Originally posted by bridgman View Post
                                The issue is that if the naming is more detailed than the ID/name mapping will support the results are actually *worse* for most users
                                Ok, but, what about this way: map names of cards which is 100% known to have some device-id and no other name use this dev-id.

                                like 4850 - 9442
                                4870 - 9440
                                4890 - 9460/9462
                                also 4850x2, 4870x2, 4770, 5770, 5750, 5870, 5850, 5970, 2600xt, 2600pro, 2900gt, 3870

                                and use r600c like method for rest of cards

                                Comment

                                Working...
                                X