[Bug 8258] drm_handle_t isn't 64bit safe
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=8258 --- Additional Comments From [EMAIL PROTECTED] 2006-09-23 00:09 --- While it is nice that the kernel ensures that drm_map_t handles (and other handles) all fit within a 32bit integer so we can have a functional 32bit userspace with a 64bit kernel, I think it's a bit shortsighted to have the userspace library simply assume that this will always be the case in the kernel code. Why not have drm_handle_t be a 64bit integer on platforms that support it? Alternatively, why use a void* for drm_map_t and drm_ctx_priv_map_t's handles when you could use a drm_handle_t, an unsigned int, an unsigned long int, or an off_t? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] partly working fragment.position patch
It turns out I missed something obvious... The parameters are passed correctly, I have just not transformed the vertex.position to the fragment.position Now I just need to figure out how =) Rune Petersen Rune Petersen wrote: Hi, Found some time to have a look at routing fragment.position from the vertex shader. Patch notes: x y appear correct, but z is 0 % w is 1. z appears to be 0 in the vertex shader, because swizzling Z to position.x is is also 0. Most of the patch is the select_vertex_shader changes by Aapo Tahkola. of interest is in r300_state.c and the bottom of r300_vertexprog.c color0 is now always passed from the vertex to the fragment, otherwise the fragment input registers wont be correctly aligned... I would be grateful for any suggestions. Rune Petersen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] partly working fragment.position patch
Rune Petersen wrote: It turns out I missed something obvious... The parameters are passed correctly, I have just not transformed the vertex.position to the fragment.position I guess that's the viewport transformation, or maybe a perspective divide followed by viewport transformation. But I think there's a bigger problem here -- somehow you're going to have to arrange for that value to be interpolated over the triangle so that each fragment ends up with the correct position. Maybe they are being interpolated already? I guess it then depends on whether the interpolation is perspective correct so that once transformed you really get the right pixel coordinates rather than just a linear interpolation across the triangle. Keith - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] partly working fragment.position patch
Keith Whitwell wrote: Rune Petersen wrote: It turns out I missed something obvious... The parameters are passed correctly, I have just not transformed the vertex.position to the fragment.position I guess that's the viewport transformation, or maybe a perspective divide followed by viewport transformation. I did do a viewport transformation, but I didn't map the z component from a range of [-1 1] to [0 1]. Perspective divide is also needed, but not in my test app (w=1) ATI appears to do perspective divide in the fragment shader. I hit a problem constructing this: - In order to do range mapping in the vertex shader (if I so choose) I will need a constant (0.5), but how to add it? - If I do perspective divide in the fragment shader, I will need to remap the WPOS from an INPUT to a TEMP. But I think there's a bigger problem here -- somehow you're going to have to arrange for that value to be interpolated over the triangle so that each fragment ends up with the correct position. Maybe they are being interpolated already? I guess it then depends on whether the interpolation is perspective correct so that once transformed you really get the right pixel coordinates rather than just a linear interpolation across the triangle. Is there a way to visually verify this? Rune Petersen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8407] New: Unknown device ID 3154
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=8407 Summary: Unknown device ID 3154 Product: DRI Version: XOrg CVS Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: General AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] I hope I'm right here to poste this, dunno actually?... I installed x11-drm on my Gentoo system as the ati driver sucks with my card. I get this error when running for example glxinfo, therefore I'm pasting it here. I have a ATI v3200 card in my laptop (IBM Thinkpad T43p), lspci reports: 01:00.0 VGA compatible controller: ATI Technologies Inc M24 1T [FireGL M24 GL] (rev 80) Running glxinfo reports: [EMAIL PROTECTED] ~ $ glxinfo |grep rendering Unknown device ID 3154, please report. Assuming plain R300. *WARN_ONCE* File r300_state.c function r300Enable line 456 TODO - double side stencil ! *** No ctx-FragmentProgram._Current!! I know that the radeon driver is still unstable for this chipset, but maybe this helps anyway. I use libdrm 2.0.2 with Xorg 7.0. Kind regards Rafael aggeler -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] partly working fragment.position patch
Rune Petersen wrote: Keith Whitwell wrote: Rune Petersen wrote: It turns out I missed something obvious... The parameters are passed correctly, I have just not transformed the vertex.position to the fragment.position I guess that's the viewport transformation, or maybe a perspective divide followed by viewport transformation. I did do a viewport transformation, but I didn't map the z component from a range of [-1 1] to [0 1]. Perspective divide is also needed, but not in my test app (w=1) ATI appears to do perspective divide in the fragment shader. I hit a problem constructing this: - In order to do range mapping in the vertex shader (if I so choose) I will need a constant (0.5), but how to add it? - If I do perspective divide in the fragment shader, I will need to remap the WPOS from an INPUT to a TEMP. But I think there's a bigger problem here -- somehow you're going to have to arrange for that value to be interpolated over the triangle so that each fragment ends up with the correct position. Maybe they are being interpolated already? I guess it then depends on whether the interpolation is perspective correct so that once transformed you really get the right pixel coordinates rather than just a linear interpolation across the triangle. Is there a way to visually verify this? Yes of course - once you've got it working, emit the position as fragment.color and have a test program read it back. If it is correct on triangles that are 'flat' but incorrect on ones that are angled away from the viewer, then it is wrong. My guess is it'll probably be fine. Keith - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8407] Unknown device ID 3154
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=8407 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-09-23 12:02 --- This message comes from the dri driver, part of mesa (r300_dri.so to be exact). id 3154 is supported since some time (and the driver would refuse to run with unknown ids completely nowadays), so update that. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] partly working fragment.position patch
Rune Petersen wrote: I hit a problem constructing this: - In order to do range mapping in the vertex shader (if I so choose) I will need a constant (0.5), but how to add it? I think this might work similar to what is used for position invariant programs, instead of using _mesa_add_state_reference you could try _mesa_add_named_parameter. Otherwise, you could always construct 0.5 in the shader itself, since you always have the constants 0 and 1 available thanks to the powerful swizzling capabilities, though surprsingly it seems somewhat complicated. Either use 2 instructions (ADD 1+1, RCP). Or try EX2/EXP though I'm not sure about performance of these, but I guess the approximated EXP should do (2^-1). Roland - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] partly working fragment.position patch
Roland Scheidegger wrote:
Rune Petersen wrote:
I hit a problem constructing this:
- In order to do range mapping in the vertex shader (if I so choose)
I will need a constant (0.5), but how to add it?
I think this might work similar to what is used for position invariant
programs, instead of using _mesa_add_state_reference you could try
_mesa_add_named_parameter. Otherwise, you could always construct 0.5
in the shader itself, since you always have the constants 0 and 1
available thanks to the powerful swizzling capabilities, though
surprsingly it seems somewhat complicated. Either use 2 instructions
(ADD 1+1, RCP). Or try EX2/EXP though I'm not sure about performance of
these, but I guess the approximated EXP should do (2^-1).
Thank you.
EXP works fine: fp/tri-depth tri-depth2 now look correct.
I tries Doom-demo (arb2) still looks bad...
Nexiuz is unstable on my system (for some unknown reason)
Are there other games that use fragment.position?
Rune Petersen
? depend
? server
Index: r300_context.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_context.h,v
retrieving revision 1.104
diff -u -r1.104 r300_context.h
--- r300_context.h 12 Sep 2006 18:34:43 - 1.104
+++ r300_context.h 23 Sep 2006 21:33:49 -
@@ -592,7 +592,8 @@
extern int hw_tcl_on;
-#define CURRENT_VERTEX_SHADER(ctx) (ctx-VertexProgram._Current)
+//#define CURRENT_VERTEX_SHADER(ctx) (ctx-VertexProgram._Current)
+#define CURRENT_VERTEX_SHADER(ctx) (R300_CONTEXT(ctx)-selected_vp)
/* Should but doesnt work */
//#define CURRENT_VERTEX_SHADER(ctx) (R300_CONTEXT(ctx)-curr_vp)
@@ -607,12 +608,18 @@
/* r300_vertex_shader_state and r300_vertex_program should probably be merged
together someday.
* Keeping them them seperate for now should ensure fixed pipeline keeps
functioning properly.
*/
+
+struct r300_vertex_program_key {
+ GLuint InputsRead;
+ GLuint OutputsWritten;
+};
+
struct r300_vertex_program {
- struct gl_vertex_program mesa_program; /* Must be first */
+ struct r300_vertex_program *next;
+ struct r300_vertex_program_key key;
int translated;
struct r300_vertex_shader_fragment program;
- struct r300_vertex_shader_fragment params;
int pos_end;
int num_temporaries; /* Number of temp vars used by program */
@@ -623,6 +630,12 @@
int use_ref_count;
};
+struct r300_vertex_program_cont {
+ struct gl_vertex_program mesa_program; /* Must be first */
+ struct r300_vertex_shader_fragment params;
+ struct r300_vertex_program *progs;
+};
+
#define PFS_MAX_ALU_INST 64
#define PFS_MAX_TEX_INST 64
#define PFS_MAX_TEX_INDIRECT 4
@@ -797,6 +810,7 @@
struct r300_cmdbuf cmdbuf;
struct r300_state state;
struct gl_vertex_program *curr_vp;
+ struct r300_vertex_program *selected_vp;
/* Vertex buffers
*/
@@ -854,9 +868,9 @@
extern int r300_get_num_verts(r300ContextPtr rmesa, int num_verts, int prim);
-void r300_translate_vertex_shader(struct r300_vertex_program *vp);
+extern void r300_select_vertex_shader(r300ContextPtr r300);
extern void r300InitShaderFuncs(struct dd_function_table *functions);
-extern int r300VertexProgUpdateParams(GLcontext *ctx, struct
r300_vertex_program *vp, float *dst);
+extern int r300VertexProgUpdateParams(GLcontext *ctx, struct
r300_vertex_program_cont *vp, float *dst);
extern int r300Fallback(GLcontext *ctx);
extern void radeon_vb_to_rvb(r300ContextPtr rmesa, struct radeon_vertex_buffer
*rvb, struct vertex_buffer *vb);
Index: r300_fragprog.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_fragprog.c,v
retrieving revision 1.29
diff -u -r1.29 r300_fragprog.c
--- r300_fragprog.c 31 Aug 2006 18:19:50 - 1.29
+++ r300_fragprog.c 23 Sep 2006 21:33:50 -
@@ -1400,6 +1400,13 @@
}
InputsRead = ~FRAG_BITS_TEX_ANY;
+ /* fragment position treated as a texcoord */
+ if (InputsRead FRAG_BIT_WPOS) {
+ cs-inputs[FRAG_ATTRIB_WPOS].refcount = 0;
+ cs-inputs[FRAG_ATTRIB_WPOS].reg = get_hw_temp(rp);
+ }
+ InputsRead = ~FRAG_BIT_WPOS;
+
/* Then primary colour */
if (InputsRead FRAG_BIT_COL0) {
cs-inputs[FRAG_ATTRIB_COL0].refcount = 0;
Index: r300_maos.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_maos.c,v
retrieving revision 1.39
diff -u -r1.39 r300_maos.c
--- r300_maos.c 14 Sep 2006 16:17:06 - 1.39
+++ r300_maos.c 23 Sep 2006 21:33:51 -
@@ -407,8 +407,8 @@
if (hw_tcl_on) {
struct r300_vertex_program *prog=(struct r300_vertex_program
*)CURRENT_VERTEX_SHADER(ctx);
inputs = prog-inputs;
-
